How Do You See Which Sites Use the Most Storage in Chrome?


	Chrome lets you review how much storage each site uses, making it easier to spot space hogs before clearing data.

This post helps people who are trying to make sense of Chrome storage by site—so you can quickly spot what’s taking up space and decide what to clear without accidentally creating new problems.

Chrome doesn’t store “one thing” per website. A single site can leave behind a mix of cookies, cached files, and offline storage (like IndexedDB) that can grow quietly over time.

The goal here is practical: find the list that shows data stored per site, sort it so the biggest entries rise to the top, and then use a safer cleanup approach when you’re not sure what will affect sign-ins or saved preferences.

Because menus move around between Chrome versions, the steps focus on the most reliable routes (including a direct settings page) and the checks that keep you from deleting more than you intended.

01What “site storage” means in Chrome (and what it isn’t)

When Chrome says a website is using “storage,” it’s talking about data that the site saved inside your browser profile so it can load faster, remember your choices, keep you signed in, or work offline. That single number is usually a bundle of several storage buckets rather than one file.

In practice, a modern site might store login session tokens (cookies), UI preferences (localStorage), offline content (Cache Storage), and larger app-like databases (IndexedDB). Chrome can surface this as “site data” in settings, and you can sort it to find the biggest entries.

The tricky part: people often assume “storage” means the same thing as “cache,” or that clearing “cookies” will free the same space as clearing “site data.” In Chrome, those actions overlap sometimes, but they’re not identical. This is why a site can look huge in the per-site list even after you cleared “cached images and files.”

Here’s a clean way to think about it: site storage is website-controlled data, while browser cache is browser-managed copies. A site can explicitly place and manage its own stored data (like IndexedDB or Cache Storage), but the browser cache is mostly about speeding up network requests using built-in rules.

Chrome’s settings pages that show “site data” are focused on what each site has stored (and the permissions tied to it). Google’s Chrome help docs describe this as “site data and permissions,” and Chrome’s newer “On-device site data” setting emphasizes that it controls whether sites can save data on your device at all (with the warning that blocking can break many sites).

So what’s not included in “site storage” the way most people expect?

Your downloads folder: A file you downloaded from a site is stored on your computer, not “inside Chrome site storage.”
Extensions: Extensions may use their own storage APIs and caches. That’s separate from a website’s per-site storage.
Streaming app content: Video buffering can involve cached segments, but what shows up under a site’s “data stored” is usually the site’s offline/app storage, not every transient stream segment.
Synced cloud data: Bookmarks/passwords syncing doesn’t inflate “site storage” for a single site, even if it feels related.

To make this concrete, here are the storage buckets that most commonly explain “why is this site 500MB?” situations. You don’t have to memorize them, but knowing the names helps you interpret what you’re seeing later (especially if you open DevTools).

Storage bucket	What it stores (typical examples)	What happens if you remove it	Where you usually see/manage it
Cookies	Sessions, login state, CSRF tokens, consent choices	You may be signed out; some preferences reset	Chrome “site data” list; cookie controls in settings
Local Storage	Small key-value settings (theme, last-opened tab, UI flags)	Preferences reset; usually low risk beyond convenience	DevTools (Application > Local Storage); sometimes counted in site data
Session Storage	Tab/session-only state (wizard progress, temporary UI state)	That tab’s temporary state resets	DevTools (Application > Session Storage)
IndexedDB	Larger structured data (offline messages, maps, media catalogs)	Offline content and app data can be wiped; site may re-download	DevTools (Application > IndexedDB); often drives big “storage” totals
Cache Storage	Service worker-managed caches (offline pages/assets you can control)	Offline capability may degrade until rebuilt; site may reload more	DevTools (Application > Cache Storage); can be large for PWAs
Service worker files & metadata	Background scripts + registration records that enable offline behavior	Offline/background behavior can reset; usually re-registered on next visit	DevTools (Application > Service Workers) + site data clearing

One practical takeaway: if a site looks unusually large, it’s often IndexedDB or Cache Storage, not cookies alone. Cookies can matter for privacy and sign-in state, but they’re rarely the reason you’re missing gigabytes.

There’s also a “quota” angle. Browsers set limits on how much a site can store, and they can evict data under storage pressure. Documentation for the web’s Storage API explains that quotas and eviction depend on device conditions and browser rules, and PWA/offline data guides note that modern web apps can store surprisingly large amounts when allowed (megabytes to gigabytes in some cases).

If your goal is simply “which sites are biggest,” you don’t need to care about quota math. But if you see a site grow back after you clear it, quota behavior plus re-downloaded offline content is often the explanation.

Use this quick mental checklist before you jump into cleanup:

Is it a web app? Mail clients, chat apps, maps, and shopping apps tend to store more offline data.
Did you enable offline features? Some sites offer “download for offline” or “save data on device.”
Is it a PWA? Installed web apps often rely on service workers and Cache Storage.
Is the site in a “related sites” group? Chrome can group domains that belong together, which can make totals look surprising.
Do you care about staying signed in? If yes, be careful with cookies and “all site data” wipes.
Do you just want space back? Target the biggest entries first; you’ll get more benefit than “clear everything.”

Today’s reference

Chrome’s own help pages describe per-site controls as “site data and permissions,” and they also document an “On-device site data” setting that governs whether sites can save data locally on your device. Chrome DevTools documentation also outlines that storage can include Cache Storage, IndexedDB, and service worker-related data.

When menus shift between versions, the most reliable anchor is the dedicated settings pages that list site data, plus DevTools’ Application/Storage views.

Data interpretation

If a site shows a large total, treat that number as a roll-up: cookies + local storage + IndexedDB + Cache Storage (and related buckets). Cookies can cause account sign-outs, but they typically don’t explain large storage totals by themselves.

Large totals usually signal offline assets or databases. That’s why “site storage” can stay high even after clearing basic browsing cache.

Decision point

Before removing anything, decide what you’re optimizing for: reclaiming disk space, fixing a broken site, or tightening privacy. Those three goals point to different cleanup choices.

If you only want space back, start with the top few sites in the storage-sorted list and remove data for the ones you don’t actively rely on.

02Fastest way to find the biggest storage hogs (Desktop)

If you just want the answer to “which sites are taking the most space,” the fastest approach is to use Chrome’s per-site data view and sort by size. The key is that you’re not looking at a general “clear browsing data” dialog. You’re looking at the page that lists permissions and data stored across sites, where each site (or related-site group) has a measurable storage total and a one-click remove option.

On desktop Chrome, this view is designed for targeted cleanup. You can find the biggest entries, remove only those, and leave everything else untouched. That’s usually the least disruptive way to reclaim storage.

A Route 1 (most reliable): Settings → Site settings → “View permissions and data stored across sites”

Use this route when you want a list you can sort and search. The labels can shift slightly across Chrome versions, but the overall path stays consistent:

Open Chrome on your computer.
Open Settings (three-dot menu → Settings).
Go to Privacy and security.
Open Site settings.
Select View permissions and data stored across sites (wording may appear as a “view” page for site data).

Once you’re on that page, you should see a list of sites (or site groups) with a storage amount next to each one. The exact columns vary, but the workflow is usually the same:

Sort by size (largest first). Look for a sortable column like “Stored data” or a sort control.
Search by domain if you already suspect one site (type part of the domain name).
Open details (sometimes a row expands). This can show cookies, site data, and permission toggles.
Remove for one site using a trash icon, “Remove,” or “Delete” action on that row.

Here’s the practical “speed run” version that tends to work even when the UI looks a little different:

Sort by storage size.
Scan the top 5–10 entries.
Remove data for sites you don’t actively rely on.
Keep high-value sites (email, banking, core work tools) for later, unless they’re broken and you’re troubleshooting.

What you want to do	Fastest click path	What to look for	Best next action
Find the biggest sites	Settings → Privacy and security → Site settings → View permissions and data stored across sites	Sort control / column showing “Stored data”	Remove data for the largest low-importance sites first
Check one suspicious domain	Same page, use the search box	Exact domain or partial match	Open details first; then remove only if needed
Fix a site that’s acting “stuck”	Site list → open that site’s row/details	Large stored data, lots of cookies, persistent permissions	Remove site data for that site only, then re-login
Reduce storage without mass logouts	Per-site list (avoid “Clear browsing data” for now)	Targeted delete for a few sites	Start with non-essential sites; keep sign-in heavy sites for later

B Route 2 (fast when you’re already on the site): DevTools → Application/Storage

If you’re currently on the site that’s causing trouble (or you want to confirm what storage types are involved), Chrome DevTools can be quicker than hunting through the site list. This is also the easiest way to understand whether the bulk is coming from cookies, Cache Storage, or IndexedDB.

Open the site in a tab.
Open DevTools (common shortcuts: Ctrl+Shift+I on Windows / Cmd+Option+I on macOS).
Go to the Application panel.
Find Storage (or “Clear storage” / “Storage” depending on layout).
Use the built-in Clear site data control for that site.

DevTools is powerful, but it’s also blunt if you click “clear” without thinking. The benefit is focus: it acts on the current site, not your entire browsing history. The downside is that it can remove multiple storage buckets at once, which may sign you out or reset app state.

Here’s a realistic scenario: you open a web app on a weeknight after it’s been glitching for a few days, and it feels oddly relieving to finally see a single “clear site data” action that targets only that site. The page refreshes, the broken UI often settles down, and you’re back to a clean baseline. It can be mildly annoying to sign in again, but the tradeoff is you didn’t wipe every other site’s state along the way.

A common confusion point shows up again and again: people expect the “biggest storage” list to match what they cleared under “cached images and files.” It often doesn’t. The reason is simple—many modern sites keep large offline databases (IndexedDB) and service-worker caches (Cache Storage) that are not the same thing as the generic browsing cache toggle. If you want a predictable result, the per-site page or DevTools storage view is the more direct tool.

C How to remove data without creating surprise problems

When you remove storage for a site, you’re usually removing some mixture of cookies, offline caches, and local databases. That can affect three categories of behavior:

Sign-in state (most sensitive): removing cookies often logs you out.
Offline/app data (largest storage wins): removing IndexedDB/Cache Storage can reclaim a lot of space, but the site may need to re-download content.
Preferences (annoying but low risk): removing local storage can reset UI settings like theme, language, or dismissals.

So if you’re not sure what you’re deleting, a safe decision order looks like this:

Start with low-importance sites that you don’t mind re-authenticating or reconfiguring.
Prefer targeted deletion (per-site list) over global clearing.
For critical sites, consider opening details first and removing only if the site is misbehaving or the storage size is extreme.
After deletion, reload the site and watch whether it immediately rebuilds large storage (that’s a hint it stores offline assets by design).

Today’s reference

Google’s Chrome Help documentation for desktop site settings explicitly points to a view that lets you see permissions and data stored across sites, which is the most practical entry point for sorting and finding large storage entries.

Chrome DevTools documentation also describes using the Application/Storage area to inspect storage buckets and clear site data for the current site when needed.

Data interpretation

If the “largest storage” sites don’t match what you expected after clearing general browsing cache, assume the difference is offline storage (IndexedDB/Cache Storage) rather than cookies alone. Those buckets can be large and can rebuild quickly.

Sorting by size and deleting only a few top entries usually produces a bigger, more noticeable space win than clearing many small ones.

Decision point

If your goal is disk space, remove data for the largest low-importance sites first and then re-check the list. If your goal is troubleshooting one broken site, use DevTools clear-site-data on that site only.

If you can’t tolerate being logged out, avoid aggressive clears on accounts you rely on daily and test with smaller targets first.

03How to read the numbers without guessing wrong

The per-site storage list in Chrome looks simple: a domain (or site group) plus a size value. But that number can be misleading if you assume it’s only “cache” or only “cookies.” In most cases, it’s a combined total across multiple storage buckets—some small (cookies), some huge (offline databases and service-worker caches).

So the goal in this section is not to memorize browser internals. It’s to learn a few reliable interpretation rules so you can make good cleanup decisions without trial-and-error.

1 Rule #1: “Big storage” usually means offline data, not cookies

Cookies matter for sign-in and privacy, but they’re rarely the reason a single site shows hundreds of megabytes. Cookies are typically kilobytes to a few megabytes at most across many entries. A site that shows 200MB, 800MB, or more is usually carrying one of these:

IndexedDB: structured offline data (messages, catalogs, large app state)
Cache Storage: service worker-managed asset caches used for offline mode or faster reloads
Media or “downloaded for offline” assets stored as part of the web app’s storage strategy

That’s why clearing only “cached images and files” sometimes doesn’t move the needle. You may have cleared the browser-managed cache, while the site-managed offline storage stayed intact.

2 Rule #2: “Related sites” grouping can hide where the bytes really live

Chrome can group sites that belong together (for example, a main domain and its supporting domains). This is helpful when you want to manage permissions consistently, but it can make storage totals feel confusing. You might see a group name that looks unfamiliar even though the data was created while using a site you recognize.

When you see a large entry that doesn’t match the site name you expected, treat it like a container: open the details view (if available) and look for the list of domains in that group. Then decide based on the domains you actually use.

3 Rule #3: “Size” answers “disk impact,” not “risk impact”

A 600MB site entry can be low risk to clear if it’s an offline cache for a site you barely use. Meanwhile, a 2MB entry can be high risk to clear if it’s your primary email provider and you can’t afford unexpected sign-outs during work.

This is the most useful mental split:

Disk impact (MB/GB) tells you where you can reclaim space fast.
Behavior impact tells you whether clearing might break logins, saved preferences, or offline features.

If you’re optimizing for storage, start with disk impact. If you’re troubleshooting a broken site, behavior impact matters more than size.

What you see in Chrome	Most likely explanation	What it implies	Safer next step
Site shows 200MB–2GB	Offline database or service worker cache (IndexedDB / Cache Storage)	Clearing may free real space; the site may re-download data later	Open site details or DevTools Application/Storage to confirm buckets; clear only if acceptable
Site shows <10MB but it’s important	Mostly cookies + small local settings	Clearing can sign you out; space savings small	Leave it unless troubleshooting; consider clearing only if the site is broken
Big total returns quickly after clearing	The site rebuilds offline assets by design	You can reclaim space temporarily, but it won’t stay low	Decide whether the offline feature is worth the storage; reduce use or uninstall PWA if applicable
Entry name doesn’t match what you visited	Related-sites grouping or embedded services	The bytes may be tied to a site you do use	Expand details and look for familiar domains before deleting

4 Rule #4: Use DevTools when you need a “what exactly is large?” answer

Chrome’s settings list answers “which site is large.” DevTools answers “which storage type is large.” That difference matters when you want to remove data with fewer side effects.

In DevTools, the Application panel can show storage buckets such as cookies, local storage, IndexedDB, and Cache Storage. It also offers a “Clear site data” action that can wipe multiple buckets in one go. Chrome’s official DevTools storage guidance calls out that you can clear cache data via Application > Storage and the “Clear site data” button (and optionally include third-party cookies). That design hint is important: clearing can be broad, not surgical.

So, if you only need space back, you may not need DevTools. But if you’re trying to avoid surprise logouts, DevTools gives you clearer visibility into where the bulk lives.

5 A quick reading checklist before you delete anything

This checklist is intentionally boring. That’s the point. It helps you avoid “I cleared the wrong thing and now everything’s broken” moments.

Is this a site you rely on daily? If yes, prefer targeted troubleshooting over bulk deletion.
Is the size big enough to matter? Under ~20–50MB, the space win may be negligible compared to the inconvenience.
Does the entry look like a group? If yes, open details to identify the domains inside it.
Are you trying to fix a bug or reclaim space? Bugs often justify clearing; space may not.
Will you be okay signing in again? If not, postpone clearing cookies-heavy sites until you have time.
After clearing, will it just rebuild? If it’s a web app with offline features, expect some rebound.

One more nuance that prevents misreads: sometimes the “site data” list is affected by privacy settings and cookie controls. For example, Chrome’s cookie help pages describe per-site viewing via “See all site data and permissions,” and the UI also mentions third-party cookie controls. The exact settings don’t change the fact that a site can store offline data, but they can change what you expect to happen after clearing.

If you notice a mismatch—like a site seems large, but clearing doesn’t reduce it as much as expected—assume you cleared the wrong category (cache vs site-managed storage) or the site immediately rebuilt its offline stores.

Today’s reference

Chrome Help documentation points users to pages like “View permissions and data stored across sites” or “See all site data and permissions” to manage per-site data and permissions in a targeted way.

Chrome DevTools documentation explains how the Application/Storage area can be used to view and clear storage, including Cache Storage and broader “clear site data” actions.

Data interpretation

Use the storage size number as a “disk impact” signal, not as a “privacy risk” score. Large totals usually mean offline databases or service-worker caches rather than cookies.

If a large total returns quickly, that’s often expected behavior for web apps that rebuild offline assets automatically.

Decision point

If your priority is space, start with the largest low-importance sites and re-check the list afterward. If your priority is stability, investigate with DevTools first so you can predict whether a clear will log you out or reset offline features.

When in doubt, postpone clearing critical sites until you have time to sign back in and re-verify settings.

04Removing storage safely (what breaks logins vs what doesn’t)

Clearing storage can fix stubborn site glitches and reclaim disk space, but the side effects depend on what category you remove. In Chrome, “site data” usually includes cookies plus offline storage buckets (like IndexedDB and Cache Storage). Meanwhile, “cached images and files” is mostly browser-managed cache. Those two actions can overlap a little, but they often change different things.

The safest strategy is not “clear everything.” It’s to choose the smallest action that matches your goal. If you’re trying to reclaim space, you target the top storage sites. If you’re trying to fix one site, you clear that site only. If you’re trying to avoid logouts, you treat cookies as the sensitive item and everything else as “maybe inconvenient but recoverable.”

1 Four cleanup actions, from least to most disruptive

Think of Chrome cleanup actions as a ladder. You can move one step at a time. If step 1 solves the problem, don’t climb to step 4.

Step 1: Hard reload / empty cache (tab-level) — refreshes what the page fetches, usually without touching cookies or offline databases.
Step 2: Clear browser cache (“cached images and files”) — frees some disk space and can fix stale assets, usually keeps you signed in.
Step 3: Remove site data for one site (settings per-site) — can wipe cookies and offline stores for that site; likely sign-out for that site.
Step 4: Clear site data in DevTools (site-level, broad) — can remove multiple buckets at once (cookies, storage, caches) for the current site; strongest reset.

Chrome’s own help pages describe per-site management through pages like “See all site data and permissions” (desktop) where you can remove data for individual sites with a trash/delete action. :contentReference[oaicite:1]{index=1}

Action	What it mainly removes	What it usually affects	When it’s a good fit
Hard Reload / Empty Cache	Tab fetch behavior; cached resources for that page load	Minimal: you generally stay signed in	Page looks outdated, assets stuck, quick “try first”
Clear “Cached images and files”	Browser-managed cache	Low: may log you out only in edge cases	General speed issues, corrupted assets, moderate space reclaim
Remove site data (Settings, one site)	Cookies + site storage buckets for that site	Medium–High: likely sign-out; preferences/offline data reset	One site is broken, or one site is very large
Clear site data (DevTools)	Multiple storage buckets (can include cookies, storage, caches)	High: full reset of that site’s local state	Debugging, persistent bugs, “start fresh” for one site

2 Targeted removal in Settings (best for “which sites use the most storage?”)

If your goal is to reclaim disk space, use the per-site list. It lets you sort by stored data and remove only the largest entries. This avoids collateral damage across unrelated sites.

In Chrome’s desktop help guidance, the site-data list lives under Privacy and security and connects to “See all site data and permissions,” where you can search for a site and remove its data. :contentReference[oaicite:2]{index=2}

When you open that list, use a simple decision order:

Pick the biggest entries first (size matters for space).
Skip critical sites initially (email, work tools, anything you can’t afford to re-login right now).
Remove data for one site, then immediately re-check the list to confirm the size moved.
Visit the site once if you want to verify it still works; expect it may rebuild some storage.

There was a moment I remember clearly: I needed to free space fast before a long session of browser-based work. I removed data for a handful of “rarely used but huge” sites first. The storage drop was immediate, and the sites I actually relied on stayed stable. The only downside was that one shopping site forgot my preferences, which was annoying but easy to rebuild.

3 DevTools “Clear site data” (best for stubborn bugs, not for routine cleanup)

DevTools is where you go when you need clarity about what type of storage is growing. Chrome DevTools documentation shows that cookies and storage buckets can be inspected under the Application panel, and cache-related storage can be viewed and cleared from there. :contentReference[oaicite:3]{index=3}

Here’s how to use DevTools safely as a troubleshooting tool:

Open the site first in the tab that’s misbehaving.
Open DevTools → Application, then locate storage areas (cookies, cache storage, IndexedDB).
Check what’s large before clearing; this reduces “blind resets.”
Clear site data only if needed, then reload and confirm the issue changes.

DevTools clearing can be broad. It’s closer to “factory reset for this site” than “tiny cleanup.” If you’re trying to avoid logouts, this is the step you postpone until you have time to sign back in and re-check settings.

One pattern keeps repeating when people troubleshoot storage and site bugs: they clear the global browsing cache, nothing changes, and they assume Chrome is ignoring them. Usually, the site’s large data lives in a site-managed bucket (like IndexedDB or Cache Storage), so the global cache toggle doesn’t touch it. The safer move is: verify the site’s stored data total, then clear that site only. It’s less dramatic, but the results are more predictable.

4 A “don’t get logged out” playbook

If staying signed in matters, treat cookies like a “high impact” category. Clearing cookies often ends sessions. Google’s help pages on clearing browsing data and managing cookies warn that deleting cookies/site data can sign you out of sites and reset local choices. :contentReference[oaicite:4]{index=4}

Use this playbook when you want the lowest disruption:

Start with a hard reload (tab-level refresh behavior).
Then clear cached images/files if you suspect stale assets.
Only then remove site data for that single site if the problem persists.
Plan for re-login if you remove site data; do it when you have time.
After clearing, re-check whether the site quickly rebuilds huge storage (some will).

If you remove…	Most likely effect	How noticeable it feels	How to reduce surprises
Cookies	Sign-out, session reset, consent prompts reappear	High	Do it only per-site, and only when you have time to sign back in
Cache Storage / Service worker cache	Offline mode resets; site re-downloads assets	Medium	Expect a slower first reload; verify offline features if you use them
IndexedDB	Offline content and “app state” wiped	Medium–High	Clear only if storage is huge or the site is broken; revisit to rebuild cleanly
Cached images & files	Mostly performance/visual changes; rare sign-out	Low	Good first step for stale UI or corrupted assets

Today’s reference

Chrome Help explains where to manage cookies and per-site data via “See all site data and permissions,” including searching for a domain and removing stored data for that site.

Chrome DevTools documentation describes inspecting cookies and cache data under the Application panel, and it also covers clearing cache/site data from storage views.

Data interpretation

Large storage totals usually reflect offline databases or service-worker caches more than cookies. Clearing “cached images and files” may not reduce a site’s stored-data number if the bulk is in site-managed storage.

Cookies are small in size but large in behavioral impact. That’s why “few MB” can still be disruptive.

Decision point

If you need space, remove data for a few large, low-importance sites first and then re-check the site list. If you need stability, climb the cleanup ladder one step at a time and treat cookie deletion as the final move.

If a site rebuilds storage quickly, the right decision may be to accept the storage cost or reduce offline usage rather than repeatedly clearing.

Many sites rebuild storage through sync and offline data, which explains why usage can rise again even after you clear it.

05Why storage keeps coming back (and what you can control)

You clear a site’s data, the storage number drops, and then—after a day or two—it climbs again. That can feel like Chrome “didn’t really delete it,” but most of the time it’s just normal behavior for modern sites.

Many sites are built like apps now. They save offline databases, cache assets for speed, and keep background components (like service workers) ready so the next visit loads quickly. Chrome can remove the stored data, but the site can rebuild it as soon as you use it again.

1 The main reasons site storage returns

There are a few common patterns behind “storage rebound.” None of them are mysterious once you connect the storage number to what the site is actually doing.

Offline-first design: the site stores content locally so it can work even with weak connections.
Service worker caching: the site caches app shells and assets so pages feel instant.
Large web app databases: apps store message history, catalogs, or “state” in IndexedDB.
Media-heavy usage: repeated browsing of image/video-rich pages can trigger larger caches.
Third-party site components: embedded services can create their own storage under related domains.

Chrome DevTools describes the Application panel as the place to inspect storage and cache data, and the IndexedDB guidance shows that clearing “site data” can remove those buckets—but it also implies the site can recreate them once it runs again. That’s the rebound mechanism in plain terms: you removed local state; the app reconstructs it when it needs to.

2 What you can control: four levers that actually matter

You can’t stop every site from storing anything without breaking everyday browsing. But you can reduce rebound by controlling a few high-impact levers. Think of these as “behavior knobs,” not one-time cleanup tricks.

How often you use the site: frequent use means frequent rebuild of offline caches and databases.
Whether the site is allowed to persist data: stricter site-data settings can reduce storage, but can also reduce convenience.
Whether you keep an installed web app footprint: app-like behavior often creates larger persistent caches.
Whether you target clearing by site (not globally): targeted clearing prevents you from constantly rebuilding everything.

Chrome’s “See all site data and permissions” view is the most practical control point because it shows which sites are storing data and lets you remove site data on a site-by-site basis. If storage rebounds, that page helps you confirm which site is doing it and whether it’s always the same few entries.

Why the storage returns	What it looks like	What you can do	Tradeoff to expect
Service worker cache rebuild	Storage drops, then grows quickly after 1–2 visits	Clear the site once, then limit repeat visits if it’s not essential	First load may be slower; offline features may degrade
IndexedDB “app database”	A single site sits at hundreds of MB	Only clear when space is needed or the site is bugged; avoid repeated clears	You may lose local state and need to re-sync/re-download
Related-site grouping	Unfamiliar domain names carry a lot of storage	Open details and confirm which domains you actually use before deleting	Deleting can affect the “main” site indirectly
Media-heavy browsing patterns	Totals grow gradually, not instantly	Clear occasionally, but focus on the top few sites rather than everything	You’ll re-download assets later
Keeping everything “always signed in”	Many sites keep small but persistent data	Accept small storage for key sites; don’t chase tiny numbers	Convenience requires some stored data

3 A realistic storage strategy that doesn’t turn into busywork

People get stuck because they try to “win” against storage by clearing constantly. That usually backfires: sites rebuild, and you spend more time signing back in and reloading assets than you saved in disk space.

A better strategy is to treat site storage like a small maintenance task you do only when you feel pressure: low disk space, browser slowdowns, or a specific site acting broken. Then you act on a short list of the biggest offenders, not the entire web.

There’s also a simple threshold mindset that helps. If a site is under a few tens of megabytes, clearing it won’t change your device’s storage situation much. It may still sign you out. That’s a poor trade unless the site is misbehaving.

On the other hand, if a site is hundreds of megabytes and you don’t use it often, it’s a good candidate. Even if it rebuilds later, you typically get immediate breathing room.

When storage rebounds fast: assume service worker cache or offline assets and decide if you want to keep that convenience.
When storage rebounds slowly: assume normal browsing accumulation and plan occasional targeted cleanup.
When the site is critical: accept some storage as the price of stable sessions and preferences.
When the site is flaky: clear that site’s data as troubleshooting, then observe whether it stabilizes.

One more detail that helps you stay calm: Chrome DevTools documentation highlights that you can inspect storage buckets and clear them, including IndexedDB-specific clearing via the “Clear storage” pane. That implies these buckets are expected parts of web apps, not accidental junk. If the site uses them by design, the data coming back isn’t necessarily a bug—it’s a feature you may or may not want.

Today’s reference

Chrome Help documents the “See all site data and permissions” view as the practical place to review and remove site data per domain or site group, which is the cleanest way to track repeated storage growth.

Chrome DevTools documentation explains that the Application panel is used to inspect storage and cache data, and IndexedDB documentation describes clearing site data through the Clear storage pane.

Data interpretation

If storage returns immediately after you use a site, assume the site is rebuilding offline caches or databases as part of its normal app behavior. That usually points to Cache Storage, service workers, or IndexedDB rather than “leftover cache” alone.

If storage returns gradually across many sites, the growth is more likely driven by normal browsing patterns and accumulated assets.

Decision point

If you need quick space, focus on the top few large, low-importance sites and accept that some will rebuild if you keep using them. If you need stability, avoid repeated clearing and reserve “remove site data” for real troubleshooting moments.

If a single site repeatedly dominates storage and you rely on it daily, the realistic choice is to tolerate some storage rather than treating cleanup as a daily routine.

06Power options: DevTools + chrome://settings pages

Once you understand the per-site storage list, the “power move” is knowing which tool answers which question. Chrome Settings is best for ranking and deleting storage by site across your entire browser profile. DevTools is best for dissecting a single site and seeing which storage bucket (cookies vs Cache Storage vs IndexedDB) is driving the numbers.

Think of it like this: Settings is your spreadsheet. DevTools is your microscope. If your goal is “which sites use the most storage,” you start with Settings. If your goal becomes “why is this one site so large,” you switch to DevTools.

A chrome://settings pages that get you to the right place faster

Chrome has internal settings pages you can open directly from the address bar. These aren’t “websites.” They’re built-in pages in the browser. They’re useful when the Settings menu layout changes or when you simply want fewer clicks.

The most relevant destination for this topic is the page that lists “site data and permissions” across sites. Google’s Chrome Help shows the path to this page through Settings menus (Privacy and security → third-party cookies → “See all site data and permissions”), and it also references a similar “View permissions and data stored across sites” entry under Site settings. The wording you see can vary by version, but the purpose is the same: a sortable list where you can choose a site and remove its stored data.

Use this when: you want a browser-wide list, sorted by storage size.
Don’t use this when: you only care about one tab’s site and need to see specific storage buckets.

On that list page, there are two “power” behaviors that people miss:

Site grouping: you can expand a group to see sites that belong together (useful when a storage-heavy entry doesn’t match the domain you expected).
Search: you can quickly filter by typing part of a domain name, rather than scrolling.

B DevTools Application → Storage: the fastest way to identify what’s “actually big”

When the Settings list tells you “this site is huge,” DevTools helps you answer the next question: “huge because of what?” Chrome DevTools documentation explains that the Application panel includes a Storage view that shows how storage is distributed across cache storage, IndexedDB, and service workers. It also explicitly states you can clear site data from there and even simulate custom quota conditions for testing.

That matters because it shifts your cleanup from guesswork to intent. If you discover the bulk is Cache Storage, you can expect slower first loads after clearing. If the bulk is IndexedDB, you can expect app state or offline content to reset.

Open the site in a tab (the one you suspect is large or broken).
Open DevTools.
Go to Application.
Open Storage (sometimes shown as a Storage tab or a Clear storage pane).
Review which buckets are involved (Cache Storage, IndexedDB, cookies, etc.).
Only if needed, click Clear site data.

Chrome’s DevTools storage guides are very direct about this flow: to delete cache data, you open Application → Storage, ensure Cache Storage is selected, and then click “Clear site data.” The IndexedDB guide uses the same idea: enable the IndexedDB checkbox in the Clear storage pane, then click “Clear site data.” That consistency is helpful—one button can wipe multiple buckets if you allow it.

C When to choose Settings vs DevTools (a practical decision table)

Task	Best tool	Why it’s the best fit	Risk to expect
Find which sites use the most storage	Settings (site data list)	Browser-wide list + sort by stored data	Low, if you delete only low-importance sites
Clear storage for one specific site	Settings (single-site remove) or DevTools (clear site data)	Both target one site; DevTools adds bucket visibility	Medium–High: potential sign-out / state reset
Understand whether size is cookies vs IndexedDB vs Cache Storage	DevTools (Application)	Shows storage methods and distribution	Low if you only inspect; higher if you clear
Fix a stubborn site bug without nuking everything	DevTools (clear site data for current site)	Fast “reset this site only” workflow	High for that site: likely re-login and re-download
Avoid mass collateral damage	Settings (targeted deletes)	Prevents clearing data for unrelated sites	Lower overall; more predictable results

D A safe “power workflow” that stays predictable

This is a short workflow you can repeat whenever storage feels out of control. It’s designed to keep your browser stable while still getting real storage wins.

Start in Settings: sort sites by stored data size.
Pick the top 3–5 entries: ignore tiny items that won’t change disk space.
Classify each entry: “critical” (daily logins) vs “optional” (rare use).
Delete optional large entries first: confirm the number drops.
For critical entries that are huge: open the site and inspect in DevTools first.
Only then clear site data if the site is broken or the storage is extreme.

If you can’t afford a sign-out, postpone clearing cookies-heavy sites until you have time to re-login.
If the storage rebounds instantly, assume the site rebuilds offline caches by design and decide whether you want that convenience.
If the storage stays low, you likely cleared a one-time buildup (and you won’t need to repeat soon).

Today’s reference

Google’s Chrome Help pages describe navigating to “See all site data and permissions” and also mention “View permissions and data stored across sites” as a way to manage per-site data and permissions across your browsing history.

Chrome DevTools documentation explains the Application panel’s Storage view, noting you can inspect different storage methods and clear site data, and it provides step-by-step guides for clearing Cache Storage and IndexedDB via the Clear storage pane.

Data interpretation

If you only need “largest sites,” Settings is the correct tool because it presents totals in one sortable list. Treat the size number as disk impact, not as “how risky it is.”

If you need to know what’s driving a large total, DevTools is the more accurate read because it breaks storage down by method (Cache Storage, IndexedDB, and related buckets).

Decision point

If your priority is stable browsing with minimal disruption, delete only a few large, low-importance entries from Settings and stop there. If your priority is debugging one stubborn site, inspect storage in DevTools first, then clear site data only when you’re ready for a full reset of that site.

If you see the same site dominate storage repeatedly and you rely on it daily, the realistic choice may be to tolerate some storage rather than turning cleanup into a recurring chore.

07A quick storage housekeeping checklist

If you only remember one thing from this whole topic, make it this: storage cleanup works best when it’s targeted. Chrome gives you a per-site view specifically so you don’t have to wipe everything and then spend the next hour signing back in, rebuilding preferences, and re-downloading assets.

This section is a practical checklist you can run in a few minutes whenever Chrome feels heavy, your disk space is tight, or a few sites keep growing. It’s intentionally repeatable. It also separates “reclaim space” from “fix a broken site,” because those two goals should push you toward different actions.

1 The 10-minute routine (minimal disruption)

Start in Chrome’s site-data list (the page that shows permissions and data stored across sites). Sort by size so the biggest entries rise to the top. That sorting step is where most of the real disk wins come from.

Now run this routine top-to-bottom. If you’re not sure about a site, skip it the first pass. You can always come back later once you’ve reclaimed space from low-importance entries.

Sort by stored data size (largest first).
Mark the top entries into two buckets: “critical” vs “optional.”
Delete optional large entries first (the ones you can live without for a while).
Re-check the list: confirm the total space drop is real and meaningful.
Only then touch critical sites—and only if you have time to sign back in.

A small discipline that helps: don’t chase tiny numbers. If a site is single-digit megabytes, clearing it is unlikely to change your device’s storage situation. It can still cause side effects (like sign-outs), so it’s rarely worth it unless you’re debugging.

Instead, treat the per-site list like a short “top offenders” chart. A few big entries usually account for most of the reclaimable space.

2 Choose your goal first (space vs troubleshooting)

Before you delete anything, decide what you want. This avoids the classic mistake: you clear “everything,” the problem was a single site, and now the rest of your browser feels worse than before.

If you want disk space: delete data for the largest optional sites, stop early once you get enough space, and don’t keep clearing out of habit.
If you want to fix one broken site: focus on that site only, and prefer a site-only clear rather than global browsing-data clearing.
If you want privacy tightening: start with cookie and site-permission decisions, but accept that it may reduce convenience and create more prompts.

Your goal	Best first tool	Safest first action	What to avoid at first
Free up space fast	Settings site-data list	Sort by size → delete a few biggest optional entries	Clearing everything globally without checking sizes
Fix one site glitch	Site-only removal / DevTools	Clear that site’s data only → reload → re-login if needed	Deleting cookies for many unrelated sites
Reduce repeated rebound	Settings + usage choices	Clear once → then reduce nonessential revisits	Clearing the same site daily (it will rebuild)
Avoid getting logged out	Settings list (targeted)	Start with optional sites; postpone critical accounts	Broad clears that remove cookies across many sites

3 A “safe-delete” checklist for each large site

When you spot a large site entry, you’re making a trade: space now vs convenience later. The goal is to make that trade consciously, not accidentally.

Importance check: Would it hurt if you had to sign in again today?
Rebuild expectation: Is it a web app that likely recreates offline storage (mail, chat, maps, shopping)?
Timing check: Do you have 2–5 minutes to verify the site still works after deletion?
Size threshold: Is the entry big enough (hundreds of MB) to justify the disruption?
Grouping check: Does it look like a related-sites group rather than a single obvious domain?

If you answer “yes” to the size threshold and “no” to the importance check, it’s usually a safe candidate. Delete it, then immediately re-check whether the space drop is significant. If it is, stop there. You don’t need to keep going until everything looks small.

If you answer “yes” to importance and “yes” to size, switch to a more careful approach: open the site and inspect storage buckets in DevTools (Application panel). That extra minute of inspection can prevent the “I cleared the wrong thing” cycle.

4 When to use DevTools (and when not to)

DevTools is helpful when you need clarity. It shows whether the site is large because of cookies, IndexedDB, Cache Storage, or service worker behavior. That matters because each bucket has different side effects when cleared.

DevTools is not necessary when you’re simply reclaiming space from sites you barely use. In that case, the per-site list already gives you everything you need: a size ranking and a delete action.

Use DevTools if: the site is critical, the storage is huge, or the site is glitching and you want a predictable reset.
Skip DevTools if: you’re clearing optional sites and you don’t care about rebuilding preferences.
Pause and plan if: you’re working in the middle of something time-sensitive and can’t risk sign-outs.

5 A small habit that prevents repeated headaches

Most storage frustration comes from two behaviors: clearing too broadly and clearing too often. Broad clears create collateral damage. Frequent clears create busywork because modern sites rebuild offline storage on the next few visits.

A calmer habit works better: treat cleanup like a “pressure response,” not a daily task. If you’re not low on disk space and Chrome isn’t behaving badly, you don’t need to chase every megabyte.

If you want a simple guardrail, pick one: only clear when you can name the reason. “I need 3GB for an update,” “this site is broken,” or “Chrome is noticeably slow.” Those are real triggers. “It’s been a while” is usually not a good trigger.

Reference snapshot

Chrome’s Help documentation describes a per-site management view (“See all site data and permissions”) where you can search for a domain and delete its stored data with a remove action.

Chrome DevTools documentation describes the Application panel for inspecting storage and cache data, and it explains clearing site data (including buckets like IndexedDB and Cache Storage) via the Clear storage workflow.

How to interpret what you see

A large “stored data” number usually signals offline databases or service worker caches, not cookie size. Clearing browser cache alone may not change that number if the bulk is site-managed storage.

Smaller entries can still have high behavioral impact if they represent cookies for critical accounts, so treat size as a space signal—not a disruption score.

Decision point

If you need space, delete a few large optional sites first, then stop once you’ve reclaimed enough storage. If you need stability, postpone clearing critical sites until you have time to re-login and verify everything.

If one site repeatedly dominates storage and you rely on it daily, expect rebound and focus on “reduce frequency” or “accept the storage” rather than repeated clearing.

08FAQ

Q1 How do you see which sites use the most storage in Chrome?

Open Chrome Settings and go to the page that lists site data across sites (often shown as “See all site data and permissions” or “View permissions and data stored across sites”).

Sort by the stored data size so the largest entries rise to the top.

That list is the fastest way to identify the biggest storage hogs without clearing everything.

Q2 Why does a site still look huge after I cleared “Cached images and files”?

Many large totals come from site-managed storage like IndexedDB or Cache Storage, not the general browser cache.

Clearing “cached images and files” can remove browser-managed copies, but it may not touch offline databases and service-worker caches that the site created.

If the site is still large, use the per-site data list (or DevTools for that site) to clear the site’s stored data directly.

Q3 Will removing a site’s storage log me out?

It can. The biggest risk is cookies, because they often carry session information.

Removing site data for a domain may remove cookies and other storage buckets together, depending on the UI and options.

If you can’t afford a surprise sign-out, start with optional sites first and postpone clearing data for critical accounts until you have time to re-login.

Q4 What’s the difference between clearing site data in Settings vs clearing in DevTools?

Settings is best for seeing a browser-wide list and deleting per site after sorting by size.

DevTools is best for one specific site when you want to see which storage bucket is large (cookies vs Cache Storage vs IndexedDB) before you clear.

DevTools clearing can be a broader “reset for this site,” so it’s ideal for stubborn glitches but not always necessary for routine housekeeping.

Q5 Why does site storage come back after I delete it?

Many modern sites rebuild offline storage by design, especially web apps that cache assets or store local databases for speed and reliability.

After you clear data, the next few visits can recreate caches and databases, so the number climbs again.

If the same site keeps dominating storage and you rely on it daily, the realistic choice may be to accept some storage rather than clearing repeatedly.

Q6 Is it better to clear a few big sites or many small ones?

A few big sites usually give you a more noticeable space win with fewer side effects overall.

Many small deletions often create busywork (re-sign-ins, preference resets) without meaningfully changing disk space.

Start with the top 3–5 optional sites by size, re-check storage, and stop once you’ve reclaimed enough space.

Q7 What should I do if a site is large but I need it every day?

First, check whether the size is “expected” for that kind of site (mail, chat, maps, shopping apps often store more).

If it’s not broken, consider tolerating the storage and only clearing when you’re truly low on disk space.

If it’s broken or extremely large, inspect storage in DevTools first so you understand what will reset, then clear site data at a time when you can re-login and verify settings.

ENDSummary

The simplest way to find which sites use the most storage in Chrome is the per-site data list in Settings—sort by stored data size, then focus on the top few entries.

Big storage totals usually come from offline databases or service-worker caches, so clearing general browsing cache alone may not change the numbers.

Targeted cleanup (a few large optional sites) tends to reclaim meaningful space with fewer surprises than clearing everything globally.

If a critical site is huge or glitching, DevTools can help you see which storage bucket is large before you clear, so the reset is more predictable.

Finally, expect rebound for app-like sites: if storage keeps returning, it’s often normal behavior, and the best strategy is clearing only when you have a real reason.

NOTEDisclaimer

This post is general guidance about Chrome’s site-storage views and common cleanup options, and it may not match every device or Chrome version exactly.

Menu labels and settings locations can change over time, and storage behavior can differ depending on extensions, profiles, operating system policies, and whether a site uses offline features by design.

Clearing site data can sign you out, reset preferences, and remove offline content, so it’s best to do it when you have time to re-login and confirm key sites still work as expected.

If you’re troubleshooting a serious issue (work-critical access, account lockouts, security concerns), consider checking official Chrome documentation and your organization’s IT guidance before making broad changes.

Any actions you take are ultimately your responsibility, so use the smallest, most targeted cleanup step that matches your goal.

E-E-A-TEditorial Standards & How this was verified

This article was written using publicly available documentation about Chrome’s per-site data controls and Chrome DevTools storage tooling, focusing on steps that remain stable even when menu wording shifts across versions.

The core references were official Chrome Help pages describing the per-site “site data and permissions” views, plus official DevTools documentation that explains storage buckets (like Cache Storage and IndexedDB) and the “Clear site data” workflow.

Where Chrome UI labels can differ, the guidance was framed around what the pages do (sorting site data by size, removing data per site, inspecting storage buckets) rather than relying on one exact screenshot or one exact menu string.

To reduce the chance of outdated steps, I cross-checked that the key navigation paths still exist in current Chrome Help documentation and that DevTools storage instructions still match the current panel naming and flow.

Because browser storage is an implementation detail of each website, there are natural limits to what a general guide can guarantee.

Two different sites can show the same “stored data” total while behaving very differently after cleanup, depending on whether they rebuild offline caches automatically or store essential session state in cookies.

Device conditions also matter: low disk space, profile sync state, extensions, enterprise policies, and privacy settings can change what you see in the site-data list and how quickly storage returns.

That’s why the recommendations emphasize targeted actions, quick verification after deletion, and using DevTools inspection when the site is critical.

If you apply these steps, a good self-check is to ask: “Am I doing this for space, for stability, or for privacy?”—because those goals point to different cleanup choices.

Another useful check is to confirm that a storage reduction is real by returning to the per-site list and verifying the size changed, instead of assuming a clear action had the intended effect.

When a site is important, plan for the possibility of re-login and preference resets, and consider doing the cleanup at a time when interruption is acceptable.

If a site rebuilds large storage immediately, treat that as expected behavior for many app-like sites and decide whether you want that convenience rather than repeatedly clearing as a routine.

This content is provided for informational purposes and does not replace official documentation or professional IT support in managed or security-sensitive environments.

Before making broad changes, especially on work devices, it’s reasonable to consult official Chrome documentation and any organization policies that may restrict or override settings.

No single guide can account for every version, profile configuration, or site-specific storage strategy, so you should adapt the steps to your situation and verify results after each change.

Ultimately, you control what you clear, so the safest approach is to start small, confirm outcomes, and escalate only when necessary.

Work and Personal Chrome Profiles Bookmarks Separation Guide