Can Chrome be started with a maximum memory setting on macOS?

No supported startup switch enforces a memory ceiling for the browser or for a tab. Chrome requests memory from the operating system as pages need it and returns it when tabs close or are deactivated. The controls that exist are the Memory Saver level, the always active exclusion list, pinned tabs, and how many distinct sites are kept open.

Do tab groups reduce memory use?

Not on their own. A collapsed group is still loaded, and grouping is an organisational feature rather than a memory feature. What reduces memory is a tab being deactivated by Memory Saver or closed outright. Groups help indirectly by making it obvious which cluster of tabs has finished its purpose.

Are memory management extensions worth installing?

Each one adds a background process of its own, so the saving has to exceed that cost before it is a net gain. Chrome's built in Memory Saver already deactivates idle tabs and can be tuned by level and exclusion. Any extension considered for this job should be checked for recent updates first, since Manifest V2 extensions can no longer be updated or reinstalled from the Chrome Web Store.

Why does closing several tabs sometimes free almost nothing?

Because memory is held per process, and pages from the same site share one. Closing six tabs of the same web application removes very little, while closing the single tab that was the only page from a heavy site can remove an entire process. Counting distinct sites gives a much better prediction than counting tabs.

How to limit Chrome memory use on a Mac

Looking for a way to limit how much memory Chrome uses is a reasonable thing to want. The browser is usually the largest single consumer on a working Mac, and it stays open longer than anything else. What makes the search frustrating is that Chrome offers no box to type a number into. The limit has to be built out of behaviour instead, and the behaviour that matters is not the one most guides start with.

The unit of memory is the process, not the tab

Chrome does not allocate memory per tab. It allocates per process, and the number of processes is decided by which sites are open rather than how many tabs are in the strip. The Chromium project states the rule plainly.

It ensures that pages from different websites are always put into different processes, each running in a sandbox that limits what the process is allowed to do. Source: chromium.org

Two consequences follow, and both change what counts as a saving.

Twelve tabs on the same web application share far less machinery than twelve tabs on twelve different services. Closing six tabs of one tool may free almost nothing. Closing the one tab that was the only visitor to a heavy site removes an entire process.

Embedded content counts as well. A page carrying a video player, a support widget, a payment frame, and an analytics dashboard from other sites is not one page as far as memory is concerned. This is why a single dashboard sometimes outweighs ten simple pages, and why a count of open tabs is a poor estimate of anything.

Anyone trying to hold usage down is therefore counting the wrong thing when counting tabs. The useful count is distinct applications kept alive.

The same rule explains a common piece of confusion. Two windows of the same profile do not halve anything, and a second monitor full of tabs is not free. What changes the arithmetic is opening fewer separate services at once, or letting the ones nobody is using go to sleep.

Memory Saver is the throttle, and it has three settings

The built in control is Memory Saver, in Settings under Performance. It works by putting unused tabs to sleep and reloading them on return. The part most people never open is the level selector.

Moderate: Get moderate memory savings. Your tabs become inactive after a longer period of time. Balanced (recommended): Get balanced memory savings. Your tabs become inactive after an optimal period of time. Maximum: Get maximum memory savings. Your tabs become inactive after a shorter period of time. Source: support.google.com

The levels change one thing only: how long a tab may sit untouched before it is deactivated. Maximum is not a stronger compression algorithm. It is a shorter fuse.

That makes the choice easy to reason about. If the working style is to open a dozen references, use them within the hour, and abandon them, Maximum reclaims that memory quickly and costs nothing, because nobody returns to those tabs anyway. If the working style is to keep the same tools open across the day and dip into each of them every few hours, Maximum guarantees a reload every single time, and Balanced or Moderate will feel better.

There is a visual aid worth turning on at the same time. The inactive tab appearance option marks sleeping tabs with a ring around the favicon, which makes the level setting concrete instead of mysterious. Without it, the only feedback is the reload itself.

Extensions are the resident cost nobody counts

Tabs are visible and get blamed. Extensions are invisible and often cost more, because an extension that runs in the background is resident whether or not anything is open. In Chrome's task manager these appear as their own rows, and a browser with a dozen extensions can be holding a meaningful amount of memory before a single page is loaded.

The audit is worth doing once a year, and the questions are short. Is this still used. Does it need to run on every site or only on a few. Is there a native application that already does the job outside the browser.

There is a second reason to look now. Chrome's Manifest V2 extensions have been disabled since Chrome 138, and the timeline states what happens to what remains.

All remaining Manifest V2 extensions are removed from the Chrome Web Store. Manifest V2 extensions installed on Chrome 138 or earlier will remain installed, but will be unable to receive any updates and cannot be reinstalled from the Chrome Web Store once removed from Chrome. Source: developer.chrome.com

Anything still installed from that generation is not being maintained. That is a good enough reason to remove it, and removing it is also a memory saving. It applies with particular force to the category of extensions that promise to manage memory, since an extra background process is being added in exchange for a promise.

Disabling, closing, and the things that only look like savings

Not every tidy up returns memory. Sorting the options by what they actually do prevents a lot of wasted effort.

Action	Effect on memory	What it costs
Close a tab	Frees it, and frees the process if it was the last tab for that site	The page and its state are gone
Pin a tab	None. Pinned tabs are exempt from deactivation	Keeps it resident on purpose
Bookmark and close	Same as closing, with the address kept	Reopening starts from scratch
Group and collapse	None by itself. A collapsed group stays loaded	Only visual order
Disable an extension	Frees its background process	The feature is off but the files remain
Second browser window	None. Same profile, same processes	Screen space only

Two rows in that table surprise people. Collapsing a tab group tidies the strip and changes nothing about what is loaded. And opening a second window of the same profile does not divide anything, because both windows draw on the same set of processes.

The pinned tab row is not a fault. Chrome lists pinned tabs among the situations where deactivation is prevented, alongside active audio or video, screen sharing, page notifications, active downloads, partially filled forms, and connected USB or Bluetooth devices. Pinning is a way of saying "keep this one alive", so it should be spent on the two or three tools that deserve it rather than on a row of twelve.

What a hard cap would actually do

It is worth being clear about what is being wished for. A browser that enforced a strict ceiling would have to evict something the moment the ceiling was reached, and it would not know which page mattered. The result would be the reload behaviour people already dislike, arriving without warning and in the middle of work.

Chrome's design puts that decision in front of the user instead: a level that governs idle time, an exclusion list for the sites that must never sleep, and a task manager to see who is expensive. That is a limit expressed as a policy rather than a number, and it can be tuned in a few minutes.

The operating system provides the genuine ceiling underneath. When memory runs short, macOS compresses inactive content and swaps to disk. Nothing needs to be configured for that, and no browser setting overrides it.

Budget for the rest of the machine, not for the browser alone

A limit only means something relative to what else has to run. On a Mac used for calls and screen sharing, or for an editor that loads large files, the browser is competing with applications that cannot be deactivated and cannot be reloaded. Deciding how much the browser may hold is really deciding how much everything else needs.

That reframing produces a more useful target than a megabyte figure. The question becomes: at the busiest moment of a normal week, which applications are running at the same time, and does the browser leave room for them. If a weekly call with screen sharing is the peak, the browser only has to be modest for that hour, and the rest of the week can be generous.

Tactics for the hour, not for the year

Short lived pressure deserves short lived measures, and these take seconds.

Close the tabs that belong to finished work rather than hiding them. Set Memory Saver to its shortest fuse for the day if a lot of references were opened and abandoned. Quit and reopen the browser before a heavy session, since a browser that has run for a week is holding state that a fresh start releases. If a video call is about to begin, close the other tabs from the same site first, because those are the ones sharing a process with it.

None of that is a permanent configuration, and it should not become one. Treating an occasional peak as the everyday setting is how people end up with an aggressive deactivation level that reloads their mail client four times a day for no reason.

The measurement to repeat

Once a month, open the task manager during ordinary work rather than after a cleanup, and note two figures: how many distinct sites appear, and how many rows are extensions. Those two numbers move slowly and predict browser memory better than any single reading of total usage. If both are climbing while the work has not changed, something is being kept open out of habit.

Set the limit at the shape of the workspace

The most durable way to hold browser memory down has nothing to do with settings. It is a decision about which applications are allowed to be permanent.

Most people can name the list without thinking: mail, chat, calendar, the project tool, one or two internal systems. Everything else is traffic. The problem is that a single window treats both categories identically, so the permanent set grows quietly, and the only correction available is a periodic purge of forty tabs.

Keeping each application in its own window makes the permanent set visible and therefore controllable. Something either has a place of its own or it does not, and the second category can be closed without a decision. The Workspaces page shows how those groups are arranged, and the Supported apps page lists what can be set up that way. For anyone weighing this against a plain multi window setup, Compared with Rambox covers where products in this category differ.

What to change first

Open Chrome's task manager, sort by memory, and count how many distinct sites are represented rather than how many tabs are open. Remove the extensions that no longer earn their background process, then set the Memory Saver level to match how long tabs really sit idle. If the permanent list is longer than five applications, the next step is giving each of them its own window instead of a shared strip, which is the arrangement SpaceDeck uses on macOS.