Google Chrome 100 tabs memory usage on a Mac

The moment that sends people looking for this number is usually physical. The fans spin up while nothing obvious is running, the pointer stalls for half a second on every click, and Activity Monitor shows a stack of processes called Google Chrome Helper (Renderer) eating most of the list. Somewhere behind that is a window, or four windows, holding roughly a hundred tabs. The question that follows is reasonable: how much memory is a hundred tabs supposed to use, and is that the actual problem.

There is no single figure, and any article that gives one is describing its own test machine rather than a Mac. What can be described precisely is the shape of the cost: which parts of Chrome scale with tab count, which parts do not, and which parts keep costing memory even after a tab looks idle. That shape is what makes the decision, because two Macs with a hundred tabs each can sit at very different numbers depending on what those tabs are.

Where the memory actually goes

Chrome does not keep one pool of memory with a hundred tabs inside it. It runs a separate renderer process per site, and that design is deliberate. The Chromium project documents it as Site Isolation, and it is the single largest reason a tab-heavy browser looks heavy in Activity Monitor.

On desktop in Chrome 67, this is about 10-13% when isolating all sites with many tabs open. Source: chromium.org

That overhead figure is the cost of the isolation itself, not the cost of the pages. The pages are the larger share, and they vary enormously. A plain article page might settle under 50 MB. A chat client with a live connection, an editor holding a document tree in memory, or a dashboard drawing charts on a timer can each hold several hundred megabytes on its own and never let go, because from the browser's point of view nothing about that tab is idle.

This is why tab count is a poor predictor. A hundred tabs of documentation and search results is a mild load. Fifteen tabs of full web applications plus eighty-five parked reference pages is a heavy one, and the eighty-five are not what is hurting. Anyone trying to fix a slow Mac by closing tabs at random is usually closing the cheap ones, because those are the ones that feel disposable.

Extensions add a second axis. Each installed extension can run its own background context, and it stays resident regardless of how many tabs are open. An extension bought to solve tab overload is itself a permanent process, which is worth remembering before installing a third one.

Measuring it instead of guessing

Two tools answer the question, and they answer different halves of it.

Chrome's own Task Manager breaks the total down per tab and per extension. On a Mac it is in the Window menu rather than behind a keyboard shortcut, and the column worth sorting by is Memory Footprint. Doing this once is usually enough to end the guessing, because the list is almost never distributed the way people expect. The top five rows tend to hold a large share of the total, and they tend to be the same five applications every day.

Chrome also exposes the figure without opening anything. In the performance settings there is a toggle described as showing memory consumption on the hover preview card for a tab, so the number appears when the pointer rests on the tab strip. For a machine that is already stalling, that is faster than opening a second window.

The second half of the question belongs to macOS, not to Chrome. Activity Monitor's Memory tab has a graph Apple defines as follows:

Graphically represents how efficiently your memory is serving your processing needs. Source: support.apple.com

The number to watch beside it is Swap Used, which Apple describes as the space being used on the startup disk to swap unused files to and from RAM. This is the distinction that matters most and gets skipped most often. Chrome holding 9 GB on a machine with plenty of headroom and a green memory pressure graph is not a problem, and closing tabs will not make anything faster. Chrome holding 5 GB on a machine that is swapping constantly is a problem, and the stalls come from the disk, not from the browser. The correct next step differs completely between those two states, so it is worth two minutes to find out which one is happening.

What Memory Saver does, and what it costs

Chrome ships with a feature aimed exactly at this situation. The help documentation describes the behaviour plainly:

Chrome deactivates tabs that you aren't currently using. When you access an inactive tab, it automatically reloads. Source: support.google.com

There are three levels, documented as Moderate, Balanced, and Maximum, differing in how long a tab sits untouched before it is deactivated. Maximum reclaims the most and reloads the most. There is also a setting that marks inactive tabs visually in the tab strip, which is worth turning on, because a discarded tab that looks identical to a live one produces a confusing reload later.

The trade is not free, and the price is paid in specific places. A reloaded tab starts from the top of the page, which loses scroll position in a long document. A form filled in but not submitted can come back empty. A page that took thirty seconds to render a report renders it again. An application in the middle of an authenticated session may return a login prompt. None of that matters for reference tabs, which is the case Memory Saver was designed for. All of it matters for the handful of applications actually being worked in, which is why the feature lets specific sites be kept active.

Setting Memory Saver to Maximum and then adding every real work application to the always-active list is a sensible configuration, and it is close to what a careful setup looks like by hand. It also reveals the underlying truth of the situation: the browser is being asked to hold two different categories of thing, and only one of them can be thrown away.

The tabs that stay expensive no matter what

After Memory Saver has done its work, whatever is left is the real load. It usually falls into a small number of categories.

Applications with an open connection stay resident because they must. Mail, chat, and task tools hold a socket so that a message arrives without a refresh, and a discarded tab cannot receive a notification. Anything relied on for alerts has effectively opted out of tab discarding, whether or not it appears on an exception list.

Editors and design tools hold documents in memory. A long document, a large spreadsheet, or a canvas with many objects has a working set that is genuinely large, and no browser setting reduces it.

Media is its own category. A background tab playing audio, or a video call, occupies both memory and CPU, and the CPU is what drains the battery.

Finally, sheer duplication has a cost that surprises people. Three tabs open on the same web application in three different accounts are three separate page loads of the same heavy code. This is the one case where the memory total genuinely tracks the number of tabs, and it is common for anyone working across more than one organisation.

Four responses, and what each one actually buys

Approach	What it reduces	What it costs	Best suited to
Close tabs manually	Whatever was closed	Time, and losing the pages later	One-off cleanups
Memory Saver on Maximum	Idle reference tabs	Reloads, lost form state and scroll position	Machines with many parked pages
A tab manager extension	Tab strip clutter, some memory	One more resident process, plus trusting it with browsing history	Research-heavy work
A window per application	Nothing directly, but stops the count climbing	Rearranging how the day is set up	Working across many web applications

The last row is the one worth sitting with, because it does not reduce memory on its own. Its value is that it changes what a hundred tabs means. When each application has a window, the applications are countable and the research tabs are visibly disposable, so closing the disposable ones stops feeling risky. Most people who solve this permanently solve it that way rather than by finding a lower number.

If a tab manager extension is on the shortlist, one check is now mandatory. Manifest V2 extensions were disabled for all users on all channels with Chrome 138, and the deprecation timeline records that all remaining Manifest V2 extensions were removed from the Chrome Web Store on August 31, 2026. A tab manager recommended in an older article may no longer exist or may no longer run, so the listing needs to be opened before the recommendation is trusted.

Why the number climbs back

The uncomfortable part of this problem is that it returns. A hundred tabs are rarely the result of carelessness. They are the residue of a working style where the browser is both the workplace and the filing cabinet, and where closing a tab feels like losing a thread. Memory settings do not touch that, which is why the same person is back at a hundred tabs a fortnight after a cleanup.

The structural version of the fix is to stop mixing the two kinds of thing. Applications used every day are not tabs in any meaningful sense: they are places, they need to stay signed in, they need to be findable in one keystroke, and they should never be closed by accident during a purge. Research pages are the opposite, and their whole value is that they can be discarded freely.

Separating them is what dedicated windows, or a browser built around one window per web application, are for. A tool of that shape keeps each application in its own persistent space with its own session, so a purge of research tabs cannot touch the mail client, and a second account on the same service does not fight the first for a cookie jar. The Workspaces page describes how that separation is arranged, and the supported apps list shows which services are set up to run that way. For anyone weighing this against the other tools in the category, the comparison with Wavebox covers what differs between them.

What to change first

Open the Chrome Task Manager once and sort by memory footprint, then check Swap Used in Activity Monitor. Those two readings decide everything: if there is no swapping, the memory total is not the problem and the tab strip is, and if there is, the top five rows show exactly what to move out of the browser first. If that list turns out to be the same five applications every day, give them somewhere permanent to live rather than a place in the queue, which is the case SpaceDeck is built for.