Fix Chrome Using Too Much Memory

Chrome’s memory usage gets blamed on Chrome itself — but the actual heavy consumption is usually one or two specific extensions running in the background, or a small number of tabs with memory-intensive content (large web apps, video players, complex dashboards). We go deeper on the whole subject in our Google Chrome Errors.

The 30-second diagnostic: press Shift+Esc inside Chrome to open Chrome’s built-in task manager. Sort by Memory column. The top 3-5 entries are typically responsible for 70%+ of Chrome’s memory usage. If an extension is at the top of that list, that’s your culprit — disable it. If specific tabs dominate the list, close those tabs (or use a session manager like OneTab to suspend them without losing them).

This is faster than any cache clearing, restart, or settings adjustment. The full guide below covers the deeper fixes when the task manager diagnostic doesn’t reveal an obvious cause — but try this first because it resolves the issue for most people in under a minute.

The Fastest Fix: Enable Memory Saver

Chrome introduced Memory Saver (originally called “Energy Saver”) in version 108 and it’s the biggest built-in solution to high memory usage that most users have never turned on. It works by putting inactive tabs to sleep — reducing them from active renderer processes consuming 200–400MB each down to near-zero memory footprint. When you click back to a sleeping tab, Chrome reloads it in a second or two.

Three-dot menu → Settings → Performance → toggle on Memory saver. That’s it. On a machine with 10 open tabs, this can reduce Chrome’s total memory footprint by 1–2GB immediately. You’ll see a little leaf icon on sleeping tabs. The practical impact on system responsiveness is noticeable on machines with 8GB or less of RAM.

The one behaviour to expect in return is Chrome reloading tabs automatically when you revisit ones it has put to sleep. It is harmless, and you can exempt specific sites if you would rather they stay loaded.

You can also exclude specific sites from sleeping — useful for things like Google Sheets you’re actively editing or a music streaming tab you need to keep active. Click “Customise” under the Memory saver toggle to add exclusions.

Find the Actual Culprit: Chrome’s Task Manager

Before disabling extensions randomly, use Chrome’s built-in task manager to see exactly where the memory is going. Press Shift + Esc while Chrome is open. This shows every open tab, every extension, and every background process with its current memory usage.

Sort by Memory footprint (click the column header). If a specific extension is using 300MB+, that’s your problem. If a single tab is using 1GB, that’s a memory-heavy page (video sites, complex web apps, and news sites with infinite scroll are frequent offenders). Armed with this information, you can target the specific process rather than making broad changes.

End any process that looks unreasonably large by selecting it and clicking End process. This immediately reclaims that memory without closing Chrome itself. The tab or extension will reload if you need it again.

Extensions: The Other Big Contributor

Extensions accumulate. An ad blocker, a password manager, a VPN, a coupon finder, a screenshot tool, and two productivity extensions each running their own background process adds up fast — easily 400–600MB before you’ve opened a single tab. Worse, some extensions have memory leaks that grow over time, meaning the longer Chrome has been open, the more memory they consume.

Go to chrome://extensions and toggle off everything you don’t actively use every day. Uninstall rather than just disable if you genuinely don’t need them — disabled extensions still have their data on disk and their code loaded in Chrome’s extension manifest. After clearing out extensions, restart Chrome and compare the memory usage in Task Manager.

A practical way to identify memory-heavy extensions without guessing: use the Chrome task manager (Shift + Esc) as described above. Extensions appear in the list by name. Any extension using more than 50–100MB consistently is worth questioning.

Clear the Cache

Over time, Chrome’s cache grows and cached data for sites that have changed can cause Chrome to hold references to old page structures in memory. This usually isn’t the primary cause of high memory usage, but it contributes — particularly on machines where Chrome has been running for weeks without a cache clear.

Ctrl + Shift + Delete → All time → Cached images and files → Clear data. After clearing, Chrome will rebuild the cache from fresh content and usually does so more efficiently than the accumulated old version. Restart Chrome after clearing to get a clean baseline memory reading.

Disable Hardware Acceleration if Memory Spikes on Certain Pages

Hardware acceleration uses the GPU for rendering, which should reduce CPU load — but on certain GPU/driver combinations it also increases memory usage by allocating large graphics buffers for Chrome’s compositor. If memory spikes specifically when scrolling through image-heavy pages or playing video, hardware acceleration is a possible contributor.

Settings → System → toggle off “Use hardware acceleration when available” → Relaunch. Check the memory usage after restarting. If there’s a noticeable improvement, update the GPU driver (Device Manager → Display Adapters → right-click → Update driver, or download from the manufacturer’s site) and then re-enable hardware acceleration — the updated driver usually handles the memory allocation more efficiently.

Stop Chrome Running in the Background

With the default settings, Chrome keeps background processes running even after you close all Chrome windows. This is for Chrome apps and extensions that need to run continuously. It means Chrome’s memory footprint doesn’t drop to zero when you close it — it drops to “background Chrome” which is typically 100–300MB.

Settings → System → toggle off “Continue running background apps when Google Chrome is closed.” After this, closing Chrome actually closes Chrome, and the memory is fully returned to the system.

Check for Malware

Cryptomining malware and browser hijackers cause memory usage that’s genuinely abnormal — not the “Chrome is using 3GB with 12 tabs” normal, but “Chrome is using 8GB with 3 tabs” abnormal. If the memory usage doesn’t match the number of tabs you have open, malware is worth ruling out before deeper Chrome troubleshooting.

Chrome’s built-in cleanup tool: Settings → Reset and clean up → Clean up computer → Find. For a more thorough scan, Malwarebytes (free) catches browser-targeting malware that Windows Defender often misses. Run both if memory usage is dramatically out of proportion to your actual Chrome usage.

Profile Corruption and New Profiles

A corrupted Chrome profile can cause memory leaks — Chrome repeatedly allocating memory for data it can’t properly parse, resulting in growing memory usage the longer a session runs. The symptom is Chrome using noticeably more memory each hour even with the same tabs open.

Test with a new profile: click the profile icon → Add → Continue without signing in. Open the same sites. If memory usage is dramatically lower in the new profile, your existing profile data is the issue. Sign into your Google account in the new profile to restore bookmarks and synced data, and reinstall your extensions selectively.

Our guide on Chrome running slow on Windows covers the performance overlap between memory pressure and general speed issues. For cases where high memory causes Chrome to actually freeze rather than just run slowly, the Chrome freezing guide covers the stability side. Google’s Chrome performance documentation covers Memory Saver configuration and Chrome’s memory management architecture in more detail.

One more practical note: 64-bit Chrome (which is the default install on modern Windows) handles memory significantly better than 32-bit Chrome because it can address more than 4GB of RAM and manages its memory pool differently. If you’re on a very old Chrome installation, checking whether you’re running 32-bit or 64-bit (three-dot menu → Help → About Google Chrome — the version info shows the bit version) is worth confirming. On a 64-bit Windows machine, you should be on 64-bit Chrome, and if you’re not, reinstalling gets you the correct version.

Tab groups and the Memory Saver interaction are worth understanding for users who keep many tabs open as a workflow tool. When tabs are grouped, Chrome’s Memory Saver treats collapsed groups differently from individual inactive tabs — collapsed groups are more aggressively put to sleep, which is beneficial for resource management. If your workflow involves keeping dozens of tabs organized by project or context, collapsing inactive groups (click the group name to collapse it) combined with Memory Saver enabled gives you the best of both worlds: tabs available without hunting for them, but not consuming active RAM until you need them.

Site-specific memory usage varies enormously and isn’t always within Chrome’s control. Google Docs and Sheets, Figma, Notion, Slack Web, and complex web applications are intentionally memory-intensive because they’re doing real computation in the browser. These apps can individually consume 500MB–1GB of RAM, which is normal and expected for the work they’re doing. If these are your high-memory tabs, the realistic solution is not Chrome settings but hardware — adding RAM to the machine. Chrome can’t make Figma use less memory any more than it could make Photoshop use less memory; the application requires what it requires. For machines stuck at 8GB RAM, being selective about which web applications run simultaneously is the practical answer rather than any Chrome configuration change.

Chrome’s renderer process sharing is a memory-related behaviour that’s non-obvious. By default, Chrome may share renderer processes between tabs from the same site — so if you have five Google Docs tabs open, they might share one or two renderer processes rather than creating five separate ones. This saves memory in multi-tab scenarios for the same service. However, this sharing breaks when Site Isolation is enabled (which it is by default for security), meaning each site gets its own process regardless. On very low-memory machines (4GB or less), some users disable Site Isolation to allow process sharing: chrome://flags → Site Isolation → disable. This is a security trade-off (Site Isolation prevents certain cross-site attacks) that is only appropriate for personal machines where the security compromise is understood and accepted. For most users, keeping Site Isolation enabled and managing memory through Memory Saver and extension reduction is the right approach.

Chrome’s memory usage pattern through a session is worth observing before troubleshooting. Memory that grows continuously through a session and never drops — even after closing tabs — indicates a memory leak in either Chrome itself, an extension, or a specific website’s JavaScript. Memory that starts high but stays roughly constant is normal Chrome behaviour. Memory that spikes when specific actions are taken (opening a specific tab, using a specific extension, visiting a specific site) and then drops when those are closed indicates a specific heavy resource consumer rather than a leak. Identifying which of these patterns applies to your situation helps direct troubleshooting: a specific heavy consumer is an extension or site issue; a continuous leak is a Chrome or extension bug that may require updating or reinstalling the offending component; a stable but high baseline is best addressed through Memory Saver and extension reduction rather than any bug fix.

Windows’ virtual memory settings affect how Chrome performs under memory pressure. When Chrome’s actual RAM usage approaches the system’s available physical RAM, Windows begins swapping memory contents to disk (paging). This is where Chrome’s memory usage causes the most noticeable performance degradation — not the memory usage itself, but the disk I/O that swapping produces. On machines with SSDs, swapping is fast and mostly invisible. On machines with HDDs, swapping is slow enough to make Chrome feel completely frozen. If Chrome high memory usage on an HDD-based machine is causing severe freezes, either reducing memory usage (through Memory Saver, fewer tabs, fewer extensions) or adding RAM has a dramatic practical impact. Increasing Windows’ virtual memory page file size (System Properties → Advanced → Performance Settings → Virtual Memory) gives Windows more room to page without as much performance impact, though this is a secondary measure compared to actually reducing memory pressure.

Prerendering and prefetching add to Chrome’s memory footprint in ways that don’t reflect active user activity. Chrome’s preloading feature (Settings → Privacy and security → Cookies and other site data → Preload pages) loads pages in the background before you click on links, using memory for those anticipated navigations. On fast machines with ample RAM this makes browsing feel snappier. On memory-constrained machines it adds unnecessary overhead for pages you might not visit. Disabling “Extended preloading” (leaving “Standard preloading” on is a reasonable middle ground) reduces background memory allocation without fully sacrificing the speed benefits of prefetching. Similarly, Chrome’s prefetch of search results as you type in the address bar consumes some memory — this can be reduced in the search engine settings by switching from “preload search results” to “basic search” if address bar prediction is contributing to memory pressure.

Chrome’s flags interface exposes some experimental memory management controls beyond the standard settings. At chrome://flags, the “Reduce User Agent” flag reduces some background memory related to browser fingerprinting; “Limit JavaScript JIT” can reduce JavaScript-related memory in exchange for slightly slower JavaScript execution on complex sites; and “Maximum tiles for interest area” controls how much memory Chrome allocates for rendering tiles when scrolling. These are experimental and may change between Chrome versions, but they’re legitimate tuning options for users willing to test and compare memory usage between configurations. The most reliable experiment: note Chrome’s memory usage before enabling a flag, run Chrome normally for an hour, and compare — small changes in these flags can produce 100–200MB differences in stable memory footprint on some systems.

When stubborn settings or leftover extensions keep memory high, resetting Chrome to a clean state is the reliable fix — and you can do it without losing your bookmarks.