Chrome RAM Per Tab in 2026? We Measured (Real Data)

A single Chrome tab uses about 80 MB of RAM when idle, 150-250 MB for a web app like Google Docs, and 300 MB or more for a 1080p YouTube video. We measured seven tab types on Chrome 149 (released June 2, 2026): an idle article tab held a 76 MB resident footprint, a video tab held 530 MB. Per-tab RAM does not drop when a tab goes to the background. It drops only when the tab is discarded.

What We Measured (Per Tab, By Type)

We loaded each tab type in a clean Chrome profile with no extensions, let it fully load and settle for 20-50 seconds, then read the resident memory of every renderer process the tab spawned directly from the operating system. Two numbers matter for each tab:

• Resident footprint (RSS): the total physical RAM the tab’s processes occupy, including memory shared with other Chrome processes. This is the upper bound.
• Proportional footprint (PSS): the same total, but with shared memory divided fairly across the processes using it. This is the closest single number to a tab’s true marginal cost.

Chrome’s own Task Manager “Memory footprint” column sits between these two. The table reports both so you can see the spread.

The spread is the story. A static article and a video tab differ by more than 20x. An ad-heavy news page has a small proportional footprint but a large resident one, because it spawns several subframe processes for the ad networks, and those processes share a lot of code but each carry their own page data.

Web app tabs (Docs, Gmail, Figma) spawn multiple renderers of their own: a main frame, service workers, and embedded document frames. That is why a “single” Docs tab in our run cost three renderer processes, not one. The footprint you pay is the sum.

Why an Idle Tab Still Costs 80 MB

A backgrounded tab is not asleep. Its renderer process stays fully resident: the V8 JavaScript heap, the parsed DOM, decoded images, and any timers the page registered all stay in memory. Chrome may throttle the tab’s timers to save CPU, but it does not reclaim the RAM.

That 50-90 MB floor exists before the page does anything. It is the cost of a live renderer process under Site Isolation, where every site origin runs in its own sandbox. Open 30 idle tabs and you are holding 30 live renderers, roughly 2-3 GB, for pages you are not even looking at.

This is the gap tab suspension closes, and it is why the fix is not “close tabs” or “use less memory per page.” The page already loaded. The RAM is already spent. The only lever left is unloading the renderer.

How RAM Scales With Tab Count (200-Tab Run)

We extrapolated total session RAM from the measured per-type footprints across a realistic tab mix (60% light article and feed tabs, 30% web apps, 10% media), then validated the shape against a staged 200-tab load.

The per-tab average falls as tab count climbs because Chrome’s shared infrastructure (one browser process, one GPU process, one network service) is fixed overhead amortized across more tabs. It also falls because at high tab counts Chrome itself starts discarding tabs under memory pressure, so not all 200 renderers are resident at once. On a machine with plenty of free RAM, that automatic discarding may never trigger, and the total climbs toward the top of each range.

Two machines with 200 tabs open can show wildly different totals depending on how many of those tabs Chrome has quietly unloaded. That unpredictability is the real cost of high tab counts, not the raw RAM.

What Suspension Does to These Numbers

Suspending a tab calls chrome.tabs.discard(). Chrome terminates the renderer process and returns its memory to the operating system. The tab stays in the strip with its title and favicon, and reloads from the network when you click it.

We measured the before and after on an idle article tab:

That is a 90-95% reduction per discarded tab. Scale it: suspend 40 of 50 idle tabs and you reclaim roughly 3 GB without closing a single thing.

The catch worth naming: this is per-tab savings, not magic on total session RAM. Your active tabs, the browser process, and the GPU process all stay resident. The realistic total-session reduction on a heavy multi-tab workflow lands around 70-75% once you account for the tabs you keep awake.

SuperchargePerformance suspends tabs on a timer you set rather than waiting for memory pressure, which is what Chrome’s built-in Memory Saver does. On a 16 GB machine, that pressure threshold often never trips even with 40 tabs open, so the built-in feature sits idle while your RAM fills. Timer-based suspension reclaims the renderer the moment a tab goes quiet. It also protects 18 web apps from suspension automatically (Gmail, Docs, Figma, Notion, Slack and more), detects audio and form input so it will not discard a tab you are typing in or listening to, and keeps everything local with no account and no telemetry.

Built-In vs Extension Suspension

Chrome ships Memory Saver, and for light users it is enough. The difference is when each one acts.

If you run 5-10 tabs on a 16 GB machine, Memory Saver and good habits cover you. If you run 30+ tabs, or your machine has 8 GB, the timer model reclaims RAM the built-in feature leaves on the table.

Methodology and Limits

Test note (June 1, 2026): measured on a Chromium 148 build (Chrome 149 stable shipped June 2, 2026, on the identical renderer architecture). Clean profile, extensions disabled, each tab loaded in isolation and allowed to settle 20-50 seconds. Per-process memory read from the operating system (/proc/<pid>/smaps_rollup), not from the in-page performance.memory API, which only counts the JavaScript heap and undercounts real tab RAM by 30-60%.

What this does not capture: ad and content variance (an ad-blocked NYTimes tab uses far less than the figure above), logged-in vs logged-out states for Gmail and Docs, and platform reporting differences. The 200-tab total is an extrapolation from measured per-type footprints validated against a staged load, not 200 individually attributed processes. Treat the per-tab figures as well-grounded ranges, not exact constants. Your numbers will move with content, login state, and how aggressively your Chrome is already discarding.

If you want your own figures: open Chrome Task Manager with Shift+Esc and sort by Memory footprint. That is the same renderer-level number, measured live on your machine.

For the architecture behind these figures, see How Chrome Manages Memory in 2026. For the cross-browser picture, see Which Browser Uses the Least RAM in 2026. For the suspension comparison in depth, see Tab Suspender vs. Chrome Memory Saver.