Chrome automatic tab discarding and memory usage

A tab that was left open two hours ago is clicked, and instead of appearing it reloads. A dashboard returns to its default filters. A half written reply is gone. Nothing crashed and nothing was closed, so the behavior looks like a bug until the mechanism behind it is named: Chrome automatic tab discarding, the trade the browser makes between memory usage and the state held inside background pages.

The trade is usually worth taking. What is not obvious is that it is adjustable in several directions at once, that a specific list of activities blocks it entirely, and that the sites where a reload actually hurts can be excluded by name. Working out which of those levers applies is more productive than turning the whole feature off.

What a discard is, precisely

Discarding is not the same as minimizing, hiding, or suspending. The page is destroyed and the tab is left behind as a placeholder.

When a tab is discarded, its title and favicon still appear in the tab strip but the page itself is gone, exactly as if the tab had been closed normally. If the user revisits that tab, the page will be reloaded automatically. Source: developer.chrome.com

That sentence explains every symptom people report. The strip looks unchanged, which is why the count of open tabs stops predicting memory usage. The page returns to whatever state a fresh load produces, which is why filters reset and scroll position is lost. And anything the site kept only in memory is unrecoverable, because there was no interruption during which it could have been saved.

The behavior itself is old. Chrome has discarded tabs under memory pressure for years, and the change in Chrome 108 was to make it routine rather than exceptional, as part of a mode presented to users as Memory Saver. Before that release, most people met a discard only when a machine was genuinely out of memory. Since then it happens on healthy machines with plenty of headroom, which is why it started being noticed and mistaken for a fault.

One consequence matters for anyone building or debugging a site. No event fires when a tab is discarded, so a page cannot react at the moment it happens. Anything a page needs to survive must be written earlier, which is the reasoning behind the widely repeated advice to persist state when a tab is backgrounded rather than when it is closing.

Memory Saver has three levels, not an on and off

The setting sits under Settings, Performance, and the level chosen there decides how aggressive the timing is.

Level	Behavior stated by Chrome
Moderate	Moderate memory savings. Tabs become inactive after a longer period of time
Balanced	Balanced memory savings, marked as recommended. Tabs become inactive after an optimal period of time
Maximum	Maximum memory savings. Tabs become inactive after a shorter period of time

Chrome does not publish the actual intervals behind those words, which is the honest reason to treat the choice as a comfort dial rather than a tuning exercise. The useful reading is directional. On a machine with abundant memory where reloads are the annoyance, Moderate reduces how often a discard happens. On a machine that is genuinely constrained, Maximum trades more reloads for more free memory.

Two adjacent settings change the experience more than the level does. Inactive tabs appearance, also under Performance, marks discarded tabs in the strip by drawing the icon inside a ring, which converts an invisible behavior into something visible before the click. Under Appearance, the option to show memory usage on the tab hover preview card puts a number on each tab, so the heavy pages can be identified rather than guessed at.

There is also a separate notification path. Performance issue alerts, on by default, prompts Chrome to recommend deactivating tabs when browsing performance degrades, offering a Fix now action. It is a distinct setting from Memory Saver itself and can be switched off independently.

Some activities block a discard entirely

Chrome will not discard a tab that is doing something it considers active, and the published list is specific enough to plan around.

The activities that prevent deactivation include active audio or video playback and calls, screen sharing, page notifications, active downloads, partially filled forms, pinned tabs, and connected USB or Bluetooth devices.

Two entries on that list deserve attention because they can be used deliberately. Pinned tabs are exempt, which makes pinning the simplest way to protect the handful of tools that run all day without touching any list. And partially filled forms are exempt, which means the nightmare case of losing a long draft is narrower than it appears, though it depends on the field being recognized as filled rather than on a site's own editor holding text in a way Chrome cannot inspect.

The list also explains inconsistent reports. A video call tab never discards, so someone whose day is meetings may never see the behavior. A documentation tab left open in the background is a prime candidate, so someone doing research sees it constantly. The same setting produces opposite impressions depending on what is open.

The exclusion list matches by pattern

For the sites where a reload is genuinely expensive, Performance has a list called Always keep these sites active. It accepts currently open sites picked from a dialog, or addresses typed by hand, and the hand typed entries follow matching rules worth learning because they are easy to get backwards.

Entering a bare domain such as google.com matches its subdomains as well, so drive.google.com and calendar.google.com are covered by the single entry. Adding a leading dot narrows it instead: .google.com will not match those subdomains. Including a path narrows it further, so www.google.com/finance protects those pages without protecting the rest of the site. Asterisks work as wildcards in the host and query components, which is what allows a pattern covering all secure sites or all videos on a given service. Wildcards used as a prefix or suffix on the host, in the style of a leading star before part of a domain name, are not supported.

The practical version of this is short. List the four or five tools where a reload costs real work, add each one as a bare domain, and leave everything else discardable. An exclusion list of thirty entries defeats the feature and is a sign that the browser is being asked to hold more running applications than a tab strip is built for. A catalog of the services that most often end up on that list is kept in Supported apps.

Verifying it rather than guessing

Two mechanisms turn this from folklore into something observable.

The first is the internal page at chrome://discards, which lists open tabs and offers an Urgent Discard action per tab. Triggering a discard by hand and then returning to the tab shows exactly what a site loses, which is a faster answer than waiting hours for the browser to do it on its own. It is the recommended way to test how a page behaves under the feature.

The second is a property the browser sets on a page that has come back from being discarded. After a reload caused by a discard, document.wasDiscarded is true, which lets a site distinguish that case from an ordinary reload and lets analytics measure how often it happens to real users. For anyone maintaining an internal tool that people leave open all day, that measurement is the difference between a suspicion and a number.

Neither mechanism can predict a discard in advance. There is no warning event and no reliable way to automate discards through standard testing tools, so the manual page remains the practical instrument.

Energy Saver is a separate mechanism on the same screen

The Performance page carries a second feature that gets blamed for discard symptoms it does not cause. Energy Saver reduces the image capture rate and other background tasks to extend battery life, and it stops eligible background tabs that are heavy on the processor. Tabs running video conferencing or playing audio are not affected.

Its trigger condition is what separates it from Memory Saver. Energy Saver works automatically when the device is unplugged or when the battery is low, and it does not turn on while the machine is plugged in. It is available on Windows, Mac and Chromebook devices that have a battery installed. So a laptop that behaves one way at a desk and another way in a meeting room is showing the effect of power state, not of a changed setting, and the browser offers a Turn off now action next to the address bar to suspend it for a single session.

The distinction matters when diagnosing a complaint. Pages that reload on click are Memory Saver at work. Animations that run at half speed, video that looks less smooth, or a background task that stops updating are Energy Saver at work. Turning off the wrong one produces no improvement and gives up something for nothing.

Other browsers approach the same power problem differently rather than not at all. Firefox, for instance, moves some background tabs onto lower power cores on macOS to reduce energy use, which leaves the pages loaded instead of unloading them. Comparing browsers on memory behavior therefore means comparing strategies, not just counting features: unloading pages, throttling them, and relocating their work to efficiency cores all reduce the number on the Activity Monitor readout in different ways and with different side effects for anything left running in the background.

When the answer is not a setting

There is a category of tab where every option above is a compromise. Mail, chat, a task tracker, a calendar, an AI assistant: these are applications that happen to be delivered as web pages, and they are open because they need to be running, not because they are being read.

Discarding treats them exactly as it treats a news article left open since morning, which is the mismatch at the root of the frustration. Excluding them keeps them alive but removes them from the memory strategy entirely, so the pages that most need to stay resident are also the ones consuming memory permanently. Pinning has the same effect through a different route.

That is the point where the shape of the container is the actual variable. Giving each of those applications its own window and its own session changes what the browser is being asked to do: the tab strip goes back to holding documents, which are cheap to discard and cheap to reload, while the running applications live somewhere that expects them to keep running. The reasoning behind that split is set out in Features, and how the memory behavior compares against other applications built on the same idea is covered in Compared with Rambox.

What to change first

Turn on Inactive tabs appearance so discards become visible, then add only the sites where a reload destroys work to Always keep these sites active. Leave the level on Balanced until there is evidence to move it. If the exclusion list keeps growing because the same tools must never reload, the browser is being used as an application host, and SpaceDeck is built for that job instead.