Chrome memory limit on macOS: what can be raised

The search for a way to raise Chrome's memory limit almost always starts with a specific moment. A tab that was left open all morning comes back blank and reloads. A spreadsheet or a design tool stalls while the fans spin. A long form is lost because the page decided to refresh itself. The instinct is to look for a number in settings and make it bigger. That number does not exist in Chrome, and knowing why changes what is worth doing instead.

Chrome has no memory ceiling to raise

There is no field in Chrome's settings that caps how much memory the browser may use, and no supported switch that hands a tab a larger allowance. Chrome takes memory from the operating system as pages ask for it, and gives it back when tabs close or go idle. The limit is not a Chrome policy. It is the machine.

That matters because the fix people are hoping for would be the wrong fix anyway. If a per tab allowance existed and were raised, the memory would still have to come from somewhere, and on a Mac that somewhere is physical RAM first, then compression, then the startup disk. Apple documents the sequence in the Activity Monitor guide.

Compressed: The amount of memory that has been compressed to make more RAM available. When your computer approaches its maximum memory capacity, inactive apps in memory are compressed, making more memory available to active apps. Source: support.apple.com

Two things follow. First, macOS is already doing what the search is asking for. Inactive content gets compressed and swapped out so that whatever is in front of you keeps its memory. Second, the honest question is not how to raise a ceiling but which parts of a browsing session are allowed to stay resident when the machine runs short.

Three different problems arrive with the same search

The symptom decides the lever. Sorting the complaint into one of three shapes takes about a minute and saves a lot of pointless configuration.

What actually happens	What is going on	The control that touches it
A tab reloads when you return to it	The tab was deactivated to free memory	Memory Saver level, or a site exclusion
The whole Mac slows down, the fans run	Memory pressure across every app, not only Chrome	Fewer resident tabs and apps, or more RAM
One tab crashes with an error page	That single renderer process hit trouble	Reduce what one page is being asked to hold

The first case is the common one and the one most often mistaken for a limit. Chrome deactivated the tab on purpose, and it reloads when it is visited again. Nothing is broken. The behaviour is adjustable.

The second case is not really a Chrome question. If Activity Monitor shows heavy swap use and yellow or red memory pressure while several native apps are open as well, changing browser settings moves the problem around rather than removing it.

The third case, a single page failing while everything else survives, is a consequence of how Chrome splits work across processes. That split is deliberate, and it is described on the Chromium project's Site Isolation page as putting pages from different sites into different processes, each in its own sandbox. One page falling over does not take the window with it.

Measure before changing anything

Chrome ships a task manager, and it answers the question that guesswork cannot: which of the open things is actually expensive. Google's own instructions are short.

Select “Memory” to sort tasks by memory usage. Source: support.google.com

It sits under the More menu, in More tools. Sort by memory once and the list usually contains one or two surprises. Extension background pages appear there as their own rows, separate from any tab, and a chat or mail app left open overnight is often heavier than the document that feels slow.

On the operating system side, the number to read in Activity Monitor is memory pressure rather than memory used. Apple describes memory pressure as determined by free memory, swap rate, wired memory, and file cached memory. A Mac that reports most of its RAM in use with low pressure is behaving correctly. Unused RAM is wasted RAM. Pressure that stays high, with swap growing, is the signal that something has to give.

Chrome can also show per tab memory in the hover preview card. On macOS the setting is under Appearance and is worded as showing memory usage in tab hover cards. It turns a vague sense that "this tab is heavy" into a figure you can compare.

The setting that behaves most like extra headroom

Since no allowance can be raised, the closest equivalent is telling Chrome which sites are never allowed to be put to sleep. Chrome calls this list "Always keep these sites active", and it lives in Settings under Performance. Adding a site there means that tab keeps its memory and its state no matter how long it sits untouched.

This is the right control for the applications where a reload costs something real: a mail client with a half written message, a project board with filters applied, an editor holding unsaved work, a dashboard that takes twenty seconds to authenticate and rebuild.

The address format is documented, and it is more precise than most people expect.

The web address format for the manual site exclusion policy is: [scheme://][.]host[:port][/path][@query] Source: support.google.com

Entering a bare domain covers its subdomains as well, so one entry can cover a whole suite of tools. Putting a dot in front of the host narrows the rule to that exact host and leaves the subdomains eligible for deactivation. Adding a path narrows it further, which is useful when only one section of a large web app is worth protecting.

Cases Chrome already refuses to touch

Some tabs are never deactivated regardless of settings, and the published list explains a lot of behaviour that otherwise looks random. Chrome documents that tab deactivation may be prevented by active audio or video playback and calls, screen sharing, page notifications, active downloads, partially filled forms, pinned tabs, and connected USB or Bluetooth devices.

The partially filled form entry is the one worth remembering, because it is the case people most fear losing. The pinned tab entry is also a practical tool. Pinning the two or three applications that must never reload achieves much of what an exclusion list does, with one click and no typing.

When one tab alone is too heavy

The exclusion list helps when tabs are being put to sleep. It does nothing for the other failure, where a single page runs out of room while the rest of the browser carries on. A large board with thousands of records, a design file with many layers, a log viewer streaming for hours, a spreadsheet used as a database. These fail on their own terms.

Because sites are placed in separate processes, the damage stays local, and so does the remedy. Reducing what that one page is asked to hold is the only lever that works: filter the view instead of loading every record, split a document that has grown into a filing cabinet, close the other tabs pointing at the same site so they are not sharing and adding to the same process, and check whether an extension is injecting work into that page on every update.

There is a related habit worth breaking. Leaving a browser running for days without ever quitting it lets long lived pages accumulate state that they would have released on a fresh load. If one application is heavy at the end of the week and light on Monday morning, the ceiling was never the problem.

Adding memory is a purchase, not a setting

The ceiling that does exist is the RAM in the machine, and it is worth being honest that this is the answer in some cases. If Activity Monitor shows sustained memory pressure with real swap use during ordinary work, and the browser is not holding anything unnecessary, no configuration will create capacity that is not there. Apple's guide includes a section on checking whether a Mac needs more RAM, which is the correct place to take that question.

Before treating it as a hardware decision, though, it is worth measuring for a week. A browser holding thirty tabs and a dozen extensions can look exactly like a machine that is short of memory, and the two cost very different amounts to fix.

Turning Memory Saver off is a trade, not an upgrade

Switching the whole feature off is a legitimate choice on a machine with plenty of RAM and a habit of keeping a modest number of tabs. Nothing gets deactivated, nothing reloads, and the memory stays committed to pages nobody is looking at.

On a machine that is already under pressure, the same change makes the Mac slower rather than faster. Memory that Chrome refuses to release has to be found elsewhere, which means compression and swap, which means disk activity in the middle of whatever you are doing. The browser stops reloading tabs and the system starts stalling instead.

The middle path is usually better than either extreme. Leave the feature on, set the deactivation level to suit how long tabs normally sit idle, and spend the exclusion list on the handful of applications where losing state actually hurts. That converts a global setting into a small, deliberate list of what deserves to stay resident.

Decide what stays resident, and give it its own window

Every approach above comes back to the same decision: which handful of things get to hold memory all day. The reason that decision is hard to keep is that a normal browser window mixes both kinds of things together. Fifteen research tabs opened this afternoon sit next to the mail client that has been open since Monday, and they are treated as peers.

Splitting the long lived applications away from disposable browsing makes the choice durable instead of a daily chore. That is the shape behind a browser that keeps each web app in its own window with its own session: mail, chat, and the project tool live in named places that persist, and everything opened for ten minutes of reading stays in a separate pile that can be closed without thought. The Workspaces page describes how that grouping is arranged, and the Features page covers what each app window keeps on its own.

The same split has a second effect on the crash case. When one heavy application misbehaves, it is in a window of its own rather than in the same window as twenty other things, so recovering means reloading one app instead of hunting through a tab strip.

What to change first

Open the task manager, sort by memory, and write down the three most expensive rows. If any of them is an extension background page for something no longer used, remove it today. Then add the two or three applications that must never reload to the always active list, and leave Memory Saver on for everything else. If the same few applications are still open next month, move them into a browser that gives each one its own window and its own session, which is the shape SpaceDeck is built around on macOS.