OBS Browser Source Memory Leak: Why 24/7 Streams Slowly Break and How to Fix It

Browser sources are convenient. They are also one of the most common causes of long-term instability in 24/7 streams.

If your stream starts fine and then fails after hours, this is one of the first things to check.

Table of Contents

1. Why browser sources cause long-term issues
2. The signs you are affected
3. Safer alternatives
4. Restart strategies that feel clean
5. When a streaming server helps

1. Why browser sources cause long-term issues

Browser sources render web content. Some web content keeps allocating memory over time.

If memory grows without stabilizing, OBS becomes unstable.

2. The signs you are affected

The stream works for a while, then quality drops, audio desync happens, or OBS crashes.

3. Safer alternatives

Keep browser sources minimal.

If you can replace a browser source with a local media file, do it.

4. Restart strategies that feel clean

If you run 24/7, plan controlled restarts.

The goal is stability, not pretending nothing ever restarts.

5. When a streaming server helps

Running the stream on a server can reduce PC instability and keep the stream online.

See /streaming for options.

Why OBS Browser sources leak memory

The Browser source in OBS embeds a CEF (Chromium Embedded Framework) instance. CEF leaks under several conditions:

• Animated SVG / canvas widgets that never garbage-collect.
• Long-running JS timers without cleanup.
• WebSocket reconnect loops that allocate buffers.
• Spotify "Now Playing" / chat overlays that re-render on every event.

A single bad Browser source can grow from 200 MB to 4-6 GB over a 24-hour stream. On a 16 GB encoder this is enough to drop frames or crash OBS.

Diagnose: which source is leaking

OBS shows per-source memory in View > Stats plus its own process is one big lump. To attribute:

# Linux
ps -eo pid,rss,comm | grep -E 'obs|cef'

# Windows
# Process Explorer (sysinternals) > expand obs64.exe tree

Each Browser source spawns a CEF child. The child eating 2+ GB is your culprit.

Settings that prevent runaway growth

Right-click Browser source > Properties:

"Shutdown source when not visible" alone fixes 90 % of leaks for scenes you switch away from.

Per-source memory caps (advanced)

Browser source supports custom CEF flags:

• Lower hardware acceleration: --disable-gpu reduces VRAM usage.
• Reduce JS heap: --js-flags=--max-old-space-size=128.

Set via OBS obs_browser.json configuration; not all builds expose this in UI.

Restart strategy for 24/7 streams

If you can't fix the leaking widget, schedule a periodic source refresh:

// in a hidden Browser source's HTML
setTimeout(() => {
  obsstudio?.refreshSource?.();   // OBS-specific browser API
}, 12 * 60 * 60 * 1000);  // every 12 hours

For overlay widgets you don't control, schedule scene reloads via obs-websocket from a small script:

# every 6 hours, refresh all browser sources
0 */6 * * * /usr/local/bin/refresh-obs-browsers.sh

Sources known to leak in 2026

• StreamElements widgets older than v5.
• Custom canvas-based "audio visualizer" templates.
• Spotify integration plugins that poll every second.
• Old Streamlabs alert overlays (newer versions are better).

When to give up on a source

If a third-party widget leaks faster than 100 MB/hour and you can't replace it, run it in a separate browser window captured via Window Capture instead. Window Capture shares memory with the desktop browser, which has its own GC and is restart-friendly.

Verification after fix

Run the stream for 4 hours. Check OBS process RSS at hour 1 and hour 4. Healthy growth: < 200 MB total. Bad growth: linear over time, will eventually OOM.

If your encoder VPS has been crashing every 36-48 hours and you can't explain why, this is the most likely cause.