Browser Storage Inspector

Web apps keep more on your device than many people realise: settings in localStorage, structured data in IndexedDB, downloaded files in the Cache API and cookies. How much of that a site may keep decides whether an offline-first app or a progressive web app is practical. This page reads what the browser reports about your storage for this site, measures the localStorage limit and shows what is stored.

The storage types

localStorage holds string key-value pairs that persist until cleared, with a small, fixed limit and a synchronous API that blocks the page while it works. sessionStorage is the same but per tab and lost when the tab closes. IndexedDB is a transactional database for structured data, blobs and large files. The Cache API stores request and response pairs, mainly for service workers. Cookies are small, are sent with requests and also hold login sessions.

Quota and usage

navigator.storage.estimate() returns the bytes this origin uses and the quota the browser allows it. Quotas are generous but variable: Chromium-based browsers allow a large share of free disk space per origin, Firefox and Safari use their own formulas and prompt or limit in some cases. Browsers deliberately blur the numbers to prevent them being used to fingerprint users, so treat them as estimates; the page shows usage as a percentage of the quota with a bar.

Best effort and persistent storage

By default, storage is “best effort”: if the device runs low on disk space, the browser may delete a site’s data, starting with sites visited least recently. A site can ask for persistent storage with navigator.storage.persist(), which exempts it from automatic eviction. Browsers decide on their own signals, such as installation as an app, bookmarks or notifications, so a request is not always granted. The button reports the outcome. Safari can also clear script-written storage for sites that have not been visited for about a week.

Testing the localStorage limit

The limit test writes a growing string under a temporary key, 256,000 characters at a time, until the browser throws an error or the test reaches about 20 million characters. It then reports the amount in characters and as UTF-16 bytes, and removes its test key. Because other keys already count against the same limit, the total includes what was stored before.

A worked example

On Chrome for desktop, one run reported that this site could hold about 4.98 million characters in localStorage, roughly 9.5 MB as UTF-16, which is why browsers are often said to allow about 5 million characters, or 10 MB measured in bytes of memory. The list above the test shows this site’s own keys, which are the saved options and last inputs of the tools you have used.

What the page cannot see

Browsers isolate storage by origin, so a page can never read another site’s localStorage, cookies or databases. HttpOnly cookies are hidden from scripts even for the same site, so the cookie count covers only readable ones. IndexedDB database names are listed only where the browser supports indexedDB.databases(). To inspect another site, open developer tools on that site and use the Application tab in Chrome and Edge or the Storage tab in Firefox.

Designing for limits

Keep localStorage for small settings, use IndexedDB for anything larger or structured, catch QuotaExceededError and degrade gracefully, and never store secrets in storage that scripts can read. Ask for persistence only after a user has invested in the data, such as after saving a project.

Related tools

• JavaScript Keycode Tester inspects another browser behaviour that varies by device.
• User-Agent Parser identifies the browser whose limits you are testing.
• Page Weight Calculator budgets what a page downloads and may cache.
• SQLite Viewer opens database files that web apps can also store locally.