Free Chrome extension

Storage Inspector

See everything a website has stored in your browser — cookies, localStorage, sessionStorage, IndexedDB, Cache Storage and service workers — in one readable place, with sizes on every key and an analyser that tells you what is wrong.

Download for ChromeChrome Web Store — in review

v1.0.0 · 70 KB · MIT licensed · Chrome, Edge, Brave, Opera and other Chromium browsers 116+

No account. No server. No AI. Nothing you look at ever leaves your browser.

6Storage areas
27Analyser checks
45+Trackers named
0Bytes uploaded
0Cost, ever

Six kinds of storage, one screen

A modern site can put data in six different places, each with its own lifetime, size limit and pitfalls. Here is what each one is, and what the extension shows you about it.

Cookies

Small key/value pairs the browser attaches to every request it sends to a domain. The original way sites remembered you, and still how nearly all login sessions work.

Lifetime
Until the expiry date the site sets, or until the browser closes if it sets none.
Capacity
About 4 KB per cookie, and roughly 180 cookies per domain.
You see
Name, value, domain, path, size, expiry as both a date and a countdown, and every flag — Secure, HttpOnly, SameSite and partitioned.

The catch: document.cookie cannot see HttpOnly cookies, so anything that reads cookies from page JavaScript shows you an incomplete list. Storage Inspector uses the extension cookie API instead, which sees all of them — including the session cookie that actually matters.

localStorage

A simple string-to-string map scoped to one origin. The most-used storage API on the web, because it takes one line to write to.

Lifetime
Forever, until the site or the user deletes it. It survives restarts.
Capacity
Around 5 MB per origin in every major browser.
You see
Every key with its size and detected type, and a decoded view — JSON pretty-printed, JWT claims read out, base64 and URL-encoding unwrapped.

The catch: It is synchronous, so reading or writing a large value blocks the main thread and shows up as visible jank. It is also readable by every script on the origin, which is why storing session tokens there turns any XSS bug into account takeover.

sessionStorage

The same API as localStorage, but scoped to a single tab and wiped when that tab closes.

Lifetime
Until the tab is closed. Each tab gets its own independent copy.
Capacity
Around 5 MB per origin, per tab.
You see
The same key list, sizes and decoding as localStorage, kept separate so you can see which of the two a value actually came from.

The catch: Duplicating a tab copies sessionStorage across; opening a fresh tab does not. That difference is behind a lot of 'it works when I refresh but not in a new tab' bug reports.

IndexedDB

A real transactional database in the browser. Asynchronous, stores structured objects rather than strings, and handles far more data than localStorage.

Lifetime
Persistent, and can be marked as protected from automatic eviction.
Capacity
A large share of free disk — commonly hundreds of megabytes to several gigabytes.
You see
Every database and version, every object store with its key path, indexes and record count, and the records themselves with per-record sizes.

The catch: The raw API is verbose enough that most people reach for a wrapper and then lose track of what is actually stored. Offline-first apps routinely accumulate hundreds of megabytes here without anyone noticing.

Cache Storage

A store of whole HTTP request/response pairs, normally filled by a service worker so a site can load offline.

Lifetime
Persistent, and entirely under the site's control — the browser never clears individual entries for you.
Capacity
Shares the same origin quota as IndexedDB.
You see
Every cache, every cached request with its status, content type and size, and which caches look like leftover versions.

The catch: Nothing expires on its own. If a service worker's activate handler forgets to delete the previous version, the old cache sits there forever — this is the single most common cause of a browser quietly holding hundreds of megabytes for one site.

Service Workers

A background script that sits between the page and the network, able to intercept requests, serve from cache and run without the page open.

Lifetime
Registered until the site or the user unregisters it. It outlives the tab.
Capacity
Not storage itself, but it is what fills Cache Storage.
You see
Scope, script URL, and the state of the active, waiting and installing worker.

The catch: A new worker installs but stays in the 'waiting' state until every tab on the origin closes. That is why users keep seeing an old build after you have deployed — and it is visible at a glance here.

What it does

A viewer is the easy part. Most of the work went into making the data readable and into the analysis on top of it.

Everything in one view

Six storage areas side by side, with a sidebar that shows what each one holds before you click into it. No hunting through nested panels to find where a value lives.

Sizes on everything

Per-key byte counts, per-area totals, a largest-keys ranking across all areas, and quota meters for localStorage, sessionStorage and the origin as a whole. You can see exactly what is filling the quota.

Values decoded, not dumped

JSON is pretty-printed. JWTs have their header and claims read out, with the expiry resolved to a real date. Base64, URL-encoding, UUIDs and Unix timestamps are all recognised and unwrapped.

A real analyser

A 0-100 storage health score built from explicit rules across security, privacy, size, expiry and hygiene. Every finding shows the evidence it matched on and suggests a concrete fix.

Search and filter

Search keys and values across any area, then narrow with one click: cookies missing Secure, cookies readable by JavaScript, known trackers, values expiring soon, credential-shaped keys, anything over 100 KB.

Delete what you select

Individual cookies and keys, whole IndexedDB databases, caches, single cache entries, or service worker registrations — with a confirmation step that lists exactly what is about to go.

Live updates

Turn on Live mode and the view re-reads storage as the page changes, so you can watch what a login flow, a checkout step or a service worker update actually writes.

Export anything

A full JSON snapshot, a value-redacted JSON snapshot that is safe to attach to a bug report, a CSV for spreadsheets, or a Markdown analysis report. All generated in the browser.

What the analysis looks like

Every finding names the rule it matched, lists the keys it matched on, and suggests a fix. Below is the extension’s actual output for the demo page bundled with it, which deliberately seeds bad practice — reproduced verbatim, findings and all.

localhost:4321 — Analysis
70C
Storage health 70 / 100

No critical issues. A few things are worth tightening up.

0 critical4 warnings8 notes
WarningExpiry

2 expired JWTs still stored

The tokens decoded cleanly but their exp claims are in the past. If the app is still sending them, every request is a guaranteed 401.

Cookieexpired_tokenexpired 4d ago
Localstale_tokenexpired 1d ago

Fix: Clear stale tokens on 401 and on logout instead of leaving them in storage.

WarningSecurity

2 credential-shaped keys in localStorage

localStorage survives browser restarts and is readable by every script on the origin. A single XSS bug — including one in a third-party script — hands these over. sessionStorage is narrower; an HttpOnly cookie is safer still.

Localaccess_token131 B
Localrefresh_token90 B

Fix: Keep session tokens in HttpOnly, Secure cookies. If the front-end must hold a token, prefer a short-lived one in memory.

InfoPrivacy

6 known tracking keys from 4 vendors

Matched against a built-in catalogue of well-known analytics, advertising and session-recording keys: Google Analytics, Meta Pixel, Hotjar, Segment. Categories present: Analytics, Advertising, Session replay.

Cookie_fbpMeta Pixel — browser-level ad attribution
Local_hjSessionUser_5551Hotjar — session recording and heatmaps

The score weights criticals at 20 points, warnings at 6, and caps all informational notes at 6 combined, so a page full of harmless notes still grades well.

Every check it runs

27 rules across five categories. All of them are plain comparisons, regular expressions and thresholds — which is why results are instant, identical every time, and work offline.

Security

The cookie-flag and token-storage mistakes that turn a small bug into a stolen session.

7
  • Cookies without Secure on an HTTPS page — sent in the clear over any HTTP request to the same domain
  • Credential-shaped cookies without HttpOnly, readable by any script via document.cookie
  • SameSite=None without Secure, which browsers reject outright so the cookie silently never arrives
  • Cookies with no SameSite attribute at all, relying on a browser default that has changed before
  • Session tokens and API keys sitting in localStorage, where they survive restarts and any XSS can read them
  • JWTs with no exp claim, which stay valid until the signing key rotates
  • JWTs using alg: none — unsigned, and therefore forgeable by anyone

Privacy

Who else is storing things on this origin, and what personal data is sitting in plain text.

4
  • Known analytics, advertising, session-recording, support and A/B testing keys, matched against a built-in catalogue of around 45 vendors
  • Which vendor each key belongs to and what it is for, rather than just labelling it a tracker
  • Cookies scoped to a domain other than the one you are on
  • Email addresses stored unencrypted in web storage

Size and quota

What is filling the quota, and what is slowing the page down.

6
  • Cookies over the 4 KB per-cookie limit browsers enforce
  • A total cookie header large enough to risk 431 responses — and paid for on every single request, including images
  • localStorage or sessionStorage approaching the 5 MB ceiling, where the next write throws QuotaExceededError
  • Origin storage quota usage, past which the browser starts refusing writes and may evict the origin
  • Individual values over 512 KB, which block the main thread every time they are read or written
  • Leftover versioned caches a service worker forgot to delete on activate

Expiry

What is about to stop working, and what already has.

6
  • Expired cookies the browser has not swept up yet
  • Cookies expiring within 24 hours — useful when a session keeps dropping mid-test
  • Cookies requesting more than 400 days, which Chrome silently caps
  • Session cookies that disappear on browser close
  • Expired JWTs still being sent, guaranteeing a 401 on every request
  • JWTs expiring within 24 hours

Hygiene

The quiet bugs and dead weight that accumulate over a project's life.

4
  • The same value stored under two or more keys, usually a migration that never cleaned up
  • Stringified bugs — keys holding "undefined", "null" or "[object Object]" because something was stored without being serialised
  • Service worker updates stuck in the waiting state, which is why users still see the old build
  • Redundant service worker registrations that failed to install

Why this exists

Chrome DevTools already shows browser storage, and for looking up one cookie it is perfectly fine. The trouble starts the moment you have a real question.

The six storage areas are six separate trees in the Application panel, so there is no way to see totals, compare areas, or find the key that is eating the quota. Sizes are shown for some areas and not others. Values are printed raw, so a JWT is an unreadable string and a JSON blob is one long line. There is no search across areas, and nothing tells you that the session cookie you are looking at is missing its Secure flag.

Storage Inspector was built to answer the questions that actually come up: what is stored here, how much of it, what does it mean, what is wrong with it, and what can I safely delete. Everything is on one page, everything has a size, values are decoded rather than dumped, and a rule engine points at the problems instead of leaving you to spot them.

It is deliberately boring technology — no framework, no build step, no dependencies, no AI, and no server. The whole thing is a few files of plain JavaScript that read your browser and render a table. That is also why it can promise your data goes nowhere: there is no code in it capable of sending data anywhere.

Compared with the DevTools Application panel

DevTools is not the enemy — it is where this started. But it is a browser feature that has to serve everyone, and a focused tool can go further in one direction.

Feature comparison between the Chrome DevTools Application panel and Storage Inspector
CapabilityDevTools Application panelStorage Inspector
All six storage areas on one screenSeparate trees per areaOne dashboard with totals
Size of every keyPartial — some areas onlyEverywhere, plus largest-keys ranking
Search across keys and valuesPer-area filter boxSearch plus one-click filters
JWT decodingNoHeader, claims and resolved expiry
JSON pretty-printingPreview column onlyFull decoded view
Security analysis of cookie flagsNoScored, with fixes
Tracker identificationNo~45 vendors named
Quota warningsNoMeters and thresholds
Export a snapshotNoJSON, redacted JSON, CSV, Markdown
Bulk delete a selectionOne row at a timeMulti-select across areas
Edit a value in placeYesNo — read and delete only
Works with no installBuilt inNeeds the extension

Who it’s for

Web developers

Find out why a session drops, why a cache will not clear, or why a user is stuck on an old build. See what a login flow actually writes, and which key the app really reads when two of them look the same.

Security engineers

Audit cookie flags and token storage in seconds rather than clicking through a panel one row at a time. Every finding names the rule it matched, so it drops straight into a report.

QA and support

Attach an exact record of what a site had stored to a bug report. The redacted export strips values but keeps the structure, sizes and findings, so it is safe to share.

Privacy researchers

Document what a site stores and which third parties it stores it for, with vendor names and purposes rather than an opaque list of key names.

People learning the web platform

Six storage APIs are hard to keep straight in the abstract. Seeing a real site's data in all of them at once, with lifetimes and quotas spelled out, makes the differences concrete.

Anyone curious

See exactly what a website is keeping on your machine — how much of it, for how long, and how much of it belongs to companies you have never visited.

Install it in two minutes

The Web Store listing is in review. Until it is live, install the ZIP the same way every extension is tested before publication — it is a standard Chrome workflow.

  1. Download and unzip

    Save the ZIP, then extract it. You should end up with a folder containing manifest.json — that folder is the extension. Keep it somewhere permanent; Chrome loads it from that path every time it starts, so deleting the folder uninstalls the extension.

  2. Open the extensions page

    Paste this into the address bar and press Enter. On Edge it is edge://extensions, and on Brave, brave://extensions.

    chrome://extensions
  3. Turn on Developer mode

    The toggle is in the top-right corner. This is what allows an extension to be loaded from a folder instead of the Web Store. It does not change anything else about how your browser behaves.

  4. Click Load unpacked

    A button appears in the top-left once Developer mode is on. Select the unzipped folder — the one with manifest.json directly inside it, not its parent.

  5. Pin it to the toolbar

    Click the puzzle-piece icon next to the address bar, find Storage Inspector, and click the pin. Now it is one click away on any site — or press Alt+Shift+S.

While any unpacked extension is installed, Chrome shows a “Developer mode extensions” notice on startup. That is Chrome describing how the extension was loaded, not a warning about this one.

Privacy

The short version: nothing is collected, because there is nothing in the extension capable of collecting it.

  • No network code at all. The extension makes no fetch, XMLHttpRequest or WebSocket calls. There is no server behind it and no endpoint to send anything to.
  • No analytics, no telemetry, no crash reporting. Not anonymised, not aggregated — none.
  • No account, no sign-in, no identifiers. There is no way to tell one user from another, even in principle.
  • Nothing is stored. What it reads is rendered into its own interface and dropped when you close it. The only thing it ever writes to disk is your own interface preferences, such as the refresh interval.
  • No remote code. Everything it runs ships inside the extension. It loads no external scripts, fonts, stylesheets or images.
  • Exports stay local.JSON, CSV and Markdown files are generated in the browser and handed straight to Chrome’s download manager. A full export contains real values including tokens, so treat it as sensitive — the redacted export exists for sharing.

Why it asks for access to all sites

A storage inspector is only useful on whichever site you happen to be debugging, and it cannot know in advance which sites those will be — an extension limited to a fixed list of domains would not do the job. That permission is used for exactly one thing: running a read-only collector on the tab you have explicitly selected, and reading that origin’s cookies. It does not run in the background, does not observe your browsing, and does nothing at all on pages where you have not opened it.

Why cookies need a special permission

HttpOnly cookies are hidden from page JavaScript by design — which is precisely why they hold session tokens. Any tool that reads cookies from inside the page shows you an incomplete list, usually missing the one that matters. Reading them properly requires the browser’s cookie permission.

Frequently asked questions

Is Storage Inspector free?

Yes, completely, with no paid tier, no trial, no account and no usage limits. It is open source under the MIT licence.

Does it send my data anywhere?

No. The extension contains no network code at all — no fetch, no XMLHttpRequest, no WebSockets, no analytics and no telemetry. There is no server behind it to receive anything. Whatever it reads is rendered into its own interface and discarded when you close it. You can verify this yourself: the source is a few files of plain JavaScript with no dependencies and no build step, so what you read is exactly what runs.

Do I need an account?

No. There is nothing to sign up for, nothing to log into, and no way to identify you even if someone wanted to.

Why does it ask for access to all websites?

A storage inspector is only useful on whichever site you happen to be debugging, and it has no way to know in advance which sites those will be — an extension restricted to a fixed list of domains would not do the job. That access is used for one thing: running a read-only collector on the tab you explicitly select. It does not track browsing, run in the background, or touch pages you have not opened it on.

How is this different from the DevTools Application panel?

DevTools shows the six storage areas as six separate trees with no totals, partial size information, raw values and no analysis. Storage Inspector puts everything on one screen with a size on every key, decodes JSON and JWTs instead of printing them raw, searches across areas, ranks the largest keys, and runs a rule engine that flags insecure cookie flags, tracker keys, quota pressure and expired tokens. DevTools can edit values in place, which Storage Inspector deliberately does not do.

Can it see HttpOnly cookies?

Yes, and this is one of the main reasons it exists as an extension rather than a bookmarklet. HttpOnly cookies are invisible to document.cookie by design — which means any page-script tool shows you an incomplete list, usually missing the session cookie you actually care about. Storage Inspector reads cookies through the browser's extension API, so it sees every one.

Does it use AI?

No. Every finding comes from an explicit rule — a comparison, a regular expression or a threshold — written out in the source. That means results are identical every time, instant, free, work offline, and can be checked line by line. An AI-based analyser would be slower, would cost money to run, would need your data sent to a server, and would occasionally invent things.

Which browsers does it work in?

Any Chromium-based browser on version 116 or newer: Chrome, Edge, Brave, Opera, Arc, Vivaldi. Firefox and Safari use different extension APIs, so they are not supported today.

Is installing from a ZIP safe?

Loading an unpacked extension is a standard developer workflow built into Chrome — it is how every extension is tested before publication. The risk with any unpacked extension is trusting whoever wrote it, which is why this one is open source: you can read every line before you load it. Chrome will show a 'Developer mode extensions' notice on startup while any unpacked extension is installed; that is expected and not a warning about this specific extension.

Will it be on the Chrome Web Store?

Yes — the listing is being prepared and submitted for review. Once it is approved, an install button will appear on this page and updates will arrive automatically. Until then, the ZIP download is the same code and works identically; the only difference is that you update it manually.

What is the storage health score?

A 0-100 number, with a letter grade, summarising what the analyser found on this origin. Critical findings cost 20 points each and warnings 6, while all informational notes together are capped at 6 — so a page with a lot of harmless notes still scores well, and one real security problem moves the needle. It is a summary, not a verdict: always read the findings themselves, because a site can score badly for reasons that are entirely deliberate.

Is deleting storage from here safe?

It does exactly what the site itself could do, and what clearing site data in browser settings does — nothing lower-level or riskier. It is still real deletion: you will be logged out if you delete a session cookie, and unsaved local data is gone. Every delete asks for confirmation and lists what is about to go. Sites often recreate what they need on the next page load.

What is in the export?

The full JSON export contains everything the scan read, including cookie values and tokens, plus the analysis. Treat it as sensitive. The redacted export replaces every value with a placeholder while keeping keys, sizes, flags, structure and findings intact — that is the one to attach to a bug report or share with a colleague. There is also a CSV for spreadsheets and a Markdown report for writing things up.

Why can it not read some pages?

Chrome blocks every extension from scripting its own internal pages (chrome://), the Chrome Web Store, other extensions' pages, and view-source views — this is a browser rule, not a limitation of this extension. Local file:// pages work if you enable 'Allow access to file URLs' on the extension's details page. Storage Inspector tells you which of these applies rather than showing an empty screen.

Does it slow down my browsing?

No. It does nothing at all until you open it — there is no content script running on every page, no background polling and no listeners on your browsing. A scan happens only when you ask for one, and typically takes a few tens of milliseconds.

Why are some IndexedDB and cache lists cut short?

Reads are capped at 200 records per object store and 300 entries per cache so that a site holding hundreds of thousands of records cannot freeze the interface. Record counts and total sizes are still complete — only the displayed rows are limited — and the dashboard says explicitly when a list has been truncated.

Why are some cache sizes approximate?

A cached response only knows its exact size if it carries a Content-Length header. Where that is missing, the extension reads the body to measure it, but only for a bounded number of entries so a large cache cannot stall the scan. Anything estimated is marked as such.

What does 'credential-shaped' mean?

The key name matches a pattern that conventionally holds a secret — access_token, session_id, api_key, jwt, password and similar. It is a name-based signal, not proof: a key called auth_prefs will be flagged and is probably harmless. The finding is a prompt to look, not a verdict.

How does it identify trackers?

By matching key names against a catalogue of well-known analytics, advertising, session-recording, support and A/B testing keys covering around 45 vendors — Google Analytics, Meta Pixel, Hotjar, Microsoft Clarity, Mixpanel, Amplitude, Segment, HubSpot and others. Matching happens entirely offline against a list shipped inside the extension. It names the vendor and what the key is for, rather than just labelling something a tracker.

Can I edit a stored value?

Not currently. Storage Inspector reads and deletes; it does not write. Keeping it read-only means it cannot corrupt the state of a site you are debugging, which matters when you are already chasing a bug. DevTools handles in-place editing well if you need it.

What people look for

Everything below is something Storage Inspector answers directly.

More free tools

Query Studio

Free SQL translator, formatter & validator

Git Rescue

Git cheat sheet & fix-it playbook

Browse all tools →