Firefox Using Too Much Memory? 5 Fixes That Work (2026)

You switch to a tab and it takes a beat to respond. The cursor hitches. Firefox is using too much memory: content processes and caches pile up faster than low-memory unloading frees them. If the browser lags and the cursor stutters, five fixes free RAM on Firefox 158 by unloading idle tabs and sweeping caches: check processes, force a memory sweep, tune process limits, enable low-memory unloading, unload the worst tab.

Fix 1: Find the process that eats memory

about:processes shows per-process memory and CPU. Open it, find the entry with the largest memory value, and use the controls there to kill a process or unload a tab. This works because the memory is separated by process, so the heavy entry is visible before you close anything.

If the large entry is a page you need, reload it after closing other heavy tabs. If the large entry is a page you no longer need, unload or kill it and leave the remaining tabs alone.

Fix 2: Force a memory sweep

about:memory exposes a “Minimize memory usage” control. Use it to ask Firefox to release what it can. This helps because Firefox keeps caches and back/forward history entries. browser.sessionhistory.max_total_viewers defaults to -1 and browser.cache.memory.capacity defaults to -1, so the values are not set to a small fixed number.

If you use long documents or many local files, a sweep can recover memory that would otherwise sit in the cache until you close the tab. If you do not want a manual sweep, the low-memory unloading pref in Fix 4 runs automatically on a timer.

Fix 3: Tune content-process limits

Settings > General > Performance offers recommended settings, hardware acceleration, and a content-process limit. For memory pressure from many processes, lower the content-process limit. The related prefs dom.ipc.processCount and dom.ipc.processCount.webIsolated default to 8 and 4. Lowering them reduces process count and memory, but you trade away per-site isolation and stability.

Use this lever when about:processes shows many processes with modest memory each. If the machine becomes unstable after lowering the limit, restore the previous value and return to the defaults of 8 and 4.

Fix 4: Enable automatic low-memory unloading

browser.tabs.unloadOnLowMemory defaults to true on macOS and Windows and to false on Linux. On macOS the check polls at 10000ms while the OS is under memory pressure, on Windows it reacts to OS low-memory events, and on Linux it polls PSI at 5000ms or 1000ms. On Linux, enable the pref before expecting automatic unloading. On macOS and Windows, the default is already on, so the automatic path depends on low-memory conditions.

If you run a Linux desktop with many inactive tabs, set the pref to true and check with the memory sweep from Fix 2. If you run macOS or Windows and memory stays high, the problem is more likely process count, cache size, or a single heavy page. If you are trying to figure out how Firefox’s memory footprint compares to Chrome’s, that comparison is covered in how Firefox stacks up against Chrome on RAM.

Fix 5: Unload one heavy tab

The tab context menu has “Unload Tab”. You can also unload a tab from about:processes. After unloading, the tab drops from about:unloads, which shows the unload priority order of still-loaded tabs and a manual Unload button for each. This is the most targeted fix when one tab is clearly larger than the rest.

If the tab holds a form, document, or video you still need, do not unload it yet. Use Fix 1 or Fix 2 first. If you no longer need the tab, unload it.

If the manual levers hold, you are done. If you do not want to repeat them, SuperchargePerformance is live on AMO as version 1.5.1 and requires Firefox 140+. It runs timer-based tab suspension with 15 minutes for Low, 5 minutes for Medium, and custom seconds on PRO. It keeps 34 protected webapp domains from suspension and carries hundreds of thousands of network-level ad/tracker blocking rules. On Firefox, suspension ranking is not memory-based.