Local Storage Test

This test does three things at once. It proves whether localStorage and sessionStorage actually work right now, it counts what is already held for this origin, and it measures how much the store will really accept before the browser refuses the write.

Availability is checked properly rather than assumed. The page writes a probe value under a known key, reads it back, compares the result, then removes it — all inside a try/catch, because a blocked store does not just return nothing, it throws on the very first write. Feature detection alone is not enough: browsers that block storage still expose the localStorage object, so a script that only checks for its existence is misled.

Browsers give each origin a budget rather than a fixed size, and the widely quoted figure is about 5 MB per origin. That is a rough norm, not a specification, and it counts UTF-16 code units, so a value of English text costs roughly two bytes per character. Firefox has historically allowed a little more than Chromium, and some builds cap a single value as well as the origin total.

To find the real number, the test writes a throwaway value, doubling or halving it until it finds the largest size that survives, then removes it. That is a binary search over roughly ten million characters, and it converges in about fourteen writes. The figure is reported in KB and shown against the 5 MB norm above.

Two honest caveats. The measurement runs while other data is present, so it reflects the space left rather than a guaranteed allocation. And the estimate of current usage counts key and value characters only; it ignores the per-entry overhead the browser adds, so treat that number as a floor.

localStorage is a plain key-value map, and the test reports how many keys this origin currently holds and roughly how much space they take. It deliberately does not print the keys or their contents: those values often belong to a login session or a preference, and there is no reason to put them on screen for a test that only needs to count them.

The count can be larger than you expect even on a first visit. Anything served from this domain shares the same store, so a theme preference, a dismissed banner, a cached draft or an analytics queue all appear. The number is also the useful part: if it stays at zero after a page claims to remember your settings, the write probably failed silently.

For a closer comparison of what each mechanism holds and when it expires, the cookies and storage test lines cookies, local storage, session storage and IndexedDB up against each other.

A blocked store is common and usually deliberate. Strict privacy settings, an extension that clears site data, an embedded third-party frame, or a browser profile configured to forget everything on close will all refuse the write. The result is a page that looks like it saved your work and then loses it on the next visit.

• Third-party context. If this page is inside an iframe on another domain, storage is partitioned or denied outright.
• Private windows. Modern Safari and Firefox allow storage in a private window but delete it when the window closes, so the write succeeds and the data still disappears.
• Full quota. A store that is already at its limit throws the same QuotaExceededError as a store that is forbidden, which is why this test reports capacity separately from availability.

If a trusted site cannot remember you, allow cookies and site data for that domain in your browser settings rather than switching everything on.

An identifier in localStorage is one of the easier ones to remove: clear site data for the origin and it is gone. That weakness is exactly why trackers spread identifiers across several stores at once, so that wiping cookies leaves the copy in IndexedDB or CacheStorage untouched. The evercookie test maps those surfaces, and the IndexedDB test covers the larger store next to this one.

Worth keeping in proportion: blocking storage narrows one channel and does nothing about the other. A device fingerprint needs no storage at all, so it survives every wipe and re-identifies the same machine. If the goal is to be less trackable rather than to be tidy, the fingerprint test shows what is actually being measured.