Storage Inspector

EditThisCookie was taken off the Chrome Web Store on 28 September 2024, and an unrelated extension has since published under the same name and is widely reported as malicious — so searching the name and installing the first result is genuinely risky. If you only need to edit cookies, a dedicated Manifest V3 cookie editor such as Cookie-Editor is the closest replacement. Storage Inspector covers cookies as one of six storage areas: it reads and edits them with validation on the flags, shows HttpOnly cookies that page JavaScript cannot see, and installs with no site access at all — cookie permission is granted per site, by you, when you ask for it.

QuotaExceededError means the origin has hit its storage quota — roughly 5 MB for localStorage in every major browser, shared across the whole origin. The fix is almost never to write less; it is to find what is already in there. Open Storage Inspector on the page and look at the largest-keys ranking: in practice it is usually one cached API response, a serialised Redux store, or an analytics library queuing events it never flushed. The quota meters show how close each area is to its limit, so you can tell whether you are near the edge before the exception starts firing. Note that IndexedDB and Cache Storage share a much larger quota, so oversized data usually belongs in one of those rather than in localStorage.

Nine times out of ten it is a service worker. A new worker installs but stays in the “waiting” state until every tab on the origin is closed, so you keep getting the previous build; and if the worker's activate handler never deletes the old cache, Cache Storage keeps serving stale responses indefinitely. Storage Inspector shows the active, waiting and installing worker side by side, and flags caches that look like leftover versions, so you can see which of the two is happening rather than guessing. A hard reload does not fix either one.

By the cookies and storage keys they leave behind — the names are fairly stable. Storage Inspector recognises around 45 vendors and labels their keys where it finds them, so _ga and _gid show as Google Analytics, _fbp as Meta, and so on, rather than sitting in the list as unexplained strings. It is a naming aid rather than a blocker: it tells you what is there, and nothing is sent anywhere for it to do that.

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

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.

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

No, and as of 1.2.0 it does not ask for it. It installs with access to no site at all — there is no host permission in its manifest, so there is nothing to approve when you add it and nothing running in the background. Clicking the toolbar icon grants it access to that one tab, for as long as that tab stays on that page, which is enough to read localStorage, sessionStorage, IndexedDB, Cache Storage and service workers with no prompt at all. Cookies are the single exception and get their own question below. If you would rather grant once and never be asked, an "Allow on all sites" option sits next to every prompt — but that is your choice to make, not the default.

Because Chrome's cookie API is the one thing the temporary per-tab access does not cover: it consults only permissions you have genuinely granted and ignores the tab grant entirely. So the first time you look at cookies on a site, the extension asks for that one site — you approve it once and are never asked for that domain again. Everything else on the page is already on screen by then; only the cookie panel waits.

Because anything narrower would show you a cookie list quietly missing rows, which is worse than showing none. Cookies are scoped to a domain rather than an exact address, so a grant limited to www.github.com would silently drop every .github.com cookie — most of the interesting ones. And Chrome files a cookie under https when it has the Secure flag and http when it does not, whatever the page that set it used, so granting one scheme would hide roughly half the list with no way for you to tell which half. It still stops at that one domain: allowing github.com tells it nothing about any other site. Registry suffixes are never wildcarded either — a page on shop.example.co.uk asks for example.co.uk, never for every .co.uk site.

Yes, at any time, and from Chrome rather than from the extension — right-click the toolbar icon and use "This can read and change site data", or open chrome://extensions and edit its site access there. Revoking is instant and needs no uninstall. The extension deliberately has no revoke button of its own: a second, subtly different control would only confuse where access actually lives.

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. Both can edit values in place; Storage Inspector shows you the old value next to the new one before it writes, and puts two confirmations in front of a delete. DevTools is built in and needs no install, which remains its real advantage.

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.

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.

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.

The Web Store, unless you have a reason not to: it is one click, it updates itself, and the build has been through Google's review. The ZIP exists for the case where you would rather read the code you are about to run — it is a few files of plain JavaScript with no build step, so what you unzip is exactly what executes, and its SHA-256 is published here. Loading unpacked is a first-class Chrome feature rather than a workaround, and grants no more power than a published extension with the same permissions; the trade-off is that it never updates itself, and Chrome shows a 'Developer mode extensions' notice on startup while any unpacked extension is installed.

Yes. It passed review and the listing is live, so the normal way to install it is the Add to Chrome button at the top of this page — one click, and it updates itself from then on. The ZIP is still here for anyone who would rather load it unpacked and read exactly what they are running; it is the same build.

Two ways. The SHA-256 hash of the exact file served from this page is published in the install section, generated when the page was built — run Get-FileHash, shasum -a 256 or sha256sum on your download and compare. Beyond that, the extension is a few files of plain JavaScript with no dependencies, no build step and no minification, so the code you unzip is exactly the code that runs; you can read all of it in an afternoon.

If you installed from the Web Store, you do not — Chrome updates it in the background, usually within a few hours of a new version being published. If you installed from the ZIP, download the new one, unzip it over the old folder (or somewhere new), then click the refresh icon on the extension's card at chrome://extensions. Either way your interface preferences survive; nothing else is stored. Unpacked extensions never update on their own, which is a feature when you want to know exactly what is running and a chore when you forget — this page always has the current version number at the top.

Only applies to a ZIP install — a Web Store install has no folder of yours to move. Loaded unpacked, it stops working, because Chrome loads it from that exact path every time it starts — it copies nothing. Put the folder somewhere permanent before you load it, not in Downloads where you might clear it out later. If you do move it, remove the entry at chrome://extensions and load it again from the new location.

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.

Both do exactly what the site itself could do, and what clearing site data in browser settings does — nothing lower-level or riskier. They are still real changes: you will be logged out if you delete a session cookie, and unsaved local data is gone. That is why deletion takes two confirmations and edits show you the old value alongside the new one before writing. Sites often recreate what they need on the next page load.

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.

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.

No, and since 1.2.0 it is not merely idle but unable to act: with no site access until you grant it, there is nothing it could run on a page you have not opened it on. There is no content script 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.

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.

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.

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.

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.

Yes. You can rewrite any cookie's value along with its Secure, HttpOnly, SameSite and expiry flags; change any localStorage or sessionStorage key, or add a new one; and edit an IndexedDB record as JSON. Every write shows the current value and the new one side by side before it is applied, so you can copy the old one first. The site sees the change immediately, exactly as if its own code had written it.

Yes, and deliberately. An IndexedDB record containing a Blob, a typed array, or anything too large to display in full is shown read-only, because what you see is a summary rather than the real record — writing it back would silently destroy the parts that are not shown. A cookie's name, domain and path are also fixed, because those three identify it: changing them would create a second cookie rather than move the first. Cache Storage entries and service worker scripts are read-only too.

Every deletion goes through two separate confirmations, because a single dialog is the one people learn to click through without reading. The first shows exactly what you selected. The second is a different question — it spells out the consequences in specific terms, such as which selected cookies look like login state and will sign you out, or that an entire IndexedDB database is going rather than just the rows on screen. For the riskiest selections — session cookies, whole databases, service workers, or more than twenty items — you also have to type the word DELETE.