FIX SBOX_FATAL_MEMORY_EXCEEDED in Chrome: 6 Fixes (2026)

Your design app dies mid-edit with “Error code: SBOX_FATAL_MEMORY_EXCEEDED” while Task Manager still shows 8 GB free. As of June 2026, that error means one tab’s renderer hit the memory ceiling Chrome’s Windows sandbox enforces. It is a per-process cap, not total RAM. Fastest fix: find and close the runaway tab.

Most guides send you to clear cache. That misses the two causes that actually produce this exact code: a single web app blowing past its one-process memory budget, and a security suite injecting a DLL that inflates the renderer. The fixes below are ordered fastest-first.

Fix 1: Find and Close the One Runaway Tab

This crash is almost always one tab, not all of them. Chrome’s own task manager pinpoints it in seconds.

1. Press Shift + Esc to open Chrome’s Task Manager.
2. Click the Memory footprint column to sort descending.
3. Look for a single tab far above the rest (a design app, a large spreadsheet, a long-lived dashboard). That is the process hitting its cap.
4. Select it and click End process, or just close the tab and reopen it fresh.

Reopening resets that renderer’s memory to near zero. If the same tab climbs back up within minutes, it has a leak. Fix 4 stops it from reaching the ceiling again.

Fix 2: Exclude Chrome From an Injecting Antivirus

A slice of SBOX_FATAL_MEMORY_EXCEEDED reports trace to security software, not Chrome. ESET shows up most in Google support threads, but any suite that injects code into the renderer can do it. The injected DLL adds to the process footprint and pushes it over the sandbox cap.

1. Open your antivirus settings and find the exclusions or exceptions list.
2. Add the Chrome program folder (C:\Program Files\Google\Chrome\Application\).
3. Restart Chrome and the antivirus.
4. If the suite has a “browser protection” or “secure browser” module, try disabling that module specifically and retest.

If excluding Chrome stops the crash, update the security suite to its latest build before re-enabling protection. Vendors patch these injection bugs, and an update often fixes it without leaving Chrome unprotected.

Fix 3: Update Chrome

The sandbox cap and the garbage-collection logic behind it both get tuned across releases. One documented variant on older builds came from Chrome’s garbage collector skipping cleanup on backgrounded tabs with no user interaction, letting memory creep until the cap tripped. That specific behavior was patched in later versions.

1. Go to chrome://settings/help.
2. Let Chrome check for and install any update.
3. Click Relaunch.
4. Confirm your build at the top of that page (Chrome 149 is current as of June 2026).

Fix 4: Suspend Idle Tabs So They Never Reach the Cap

If the crash returns on the same heavy web app, the durable fix is keeping fewer renderers alive at the ceiling. A backgrounded tab you are not looking at does not need to hold its full memory footprint. Suspending it discards the renderer and frees that memory until you click back.

1. Open Settings > Performance (chrome://settings/performance).
2. Turn on Memory Saver.
3. Optionally add your always-on apps (mail, calendar) to the “Always keep these sites active” list so they are not suspended mid-task.

Chrome’s built-in Memory Saver reclaims roughly 30–40% of total Chrome RAM by its own figure, and it inactivates idle tabs on a fixed timer you cannot tighten. For a tab that leaks fast, a shorter, configurable timer keeps it from ever climbing to the sandbox cap. That gap is what the section near the end covers.

Fix 5: Disable Hardware Acceleration (If It Crashes on GPU-Heavy Pages)

When SBOX_FATAL_MEMORY_EXCEEDED hits on pages with video, WebGL, or 3D design tools, the GPU process and renderer can balloon together. Turning off hardware acceleration removes that pressure as a test.

1. Go to Settings > System (chrome://settings/system).
2. Toggle off Use graphics acceleration when available.
3. Click Relaunch and retest the page that crashed.
4. If the crash stops, update your GPU drivers, then re-enable acceleration to restore smooth video.

This is a diagnostic step, not a permanent setting. Leaving acceleration off slows video and canvas rendering, so re-enable it once drivers are current.

Fix 6: Reset Chrome Flags and Profile

A corrupt profile or a stuck experimental flag can keep one renderer wedged near its cap on every launch.

1. Visit chrome://flags and click Reset all at the top right, then relaunch.
2. If the crash still hits a specific tab on startup, the profile may be corrupt. Open chrome://version, note the Profile Path, close Chrome, and rename that profile folder (for example Default to Default.old).
3. Relaunch. Chrome builds a clean profile. Sign back in to restore bookmarks and history through Chrome Sync.

Why SBOX_FATAL_MEMORY_EXCEEDED Is a Per-Tab Limit, Not Low RAM

Chrome runs each tab in an isolated renderer process wrapped in a Windows sandbox. The sandbox assigns that process a memory job-object limit for security and stability. When one renderer’s allocations cross that per-process ceiling, Chrome terminates it with SBOX_FATAL_MEMORY_EXCEEDED rather than letting it consume the machine. That design is why the error appears with plenty of system RAM still free: the cap that was exceeded belongs to one process, not the whole computer.

Keeping Heavy Tabs Below the Sandbox Ceiling

The pattern behind most repeat SBOX_FATAL_MEMORY_EXCEEDED crashes is a single long-lived web app that slowly climbs toward its per-process cap while you work in other tabs. SuperchargePerformance suspends idle tabs with chrome.tabs.discard(), which releases that renderer’s memory the moment you switch away and rebuilds it when you return. A discarded tab cannot reach its sandbox ceiling, so the crash never fires on the app you left in the background.

It runs a configurable suspension timer rather than Chrome’s fixed one, so a fast-leaking dashboard can be parked in minutes instead of waiting on Memory Saver’s longer interval. It also protects 29 web apps (Gmail, Docs, Sheets, Figma, Notion, Slack, plus media and call apps like Spotify, Zoom, and Google Meet) from suspension so an active document never discards mid-edit, and it skips any tab that is playing audio, holds unsaved form input, or is pinned.

Per discarded tab, the reclaimed renderer memory is the full footprint of that tab (90–95% of what it held). Across a working session, suspended tabs typically cut total Chrome RAM by 70–75%. It stores everything locally, asks for no account, and sends no telemetry.

If the Crash Persists

If you have closed the runaway tab, excluded Chrome from your antivirus, and updated to the current build and SBOX_FATAL_MEMORY_EXCEEDED still returns, narrow it down by trigger:

• Crashes on one specific web app every time → suspend it in the background and reload it fresh when needed, rather than leaving it open for hours.
• Crashes only with a security suite running → keep Chrome excluded and wait for the vendor’s next patch.
• Crashes on GPU-heavy pages → update graphics drivers (Fix 5), since the renderer and GPU process inflate together there.

For the broader memory picture, see fixing Chrome Out of Memory and the Aw, Snap crash.