Evercookie Test

The idea is simple and slightly rude. Instead of trusting one cookie to remember you, a script writes the same identifier into every store it can reach, then checks each of them on your next visit and restores any that are missing. Delete the cookie and local storage quietly hands the value back; clear local storage and the copy in IndexedDB fills the gap.

The point is redundancy. Every individual mechanism is easy to clear, but clearing all of them at once is more effort than most people make, and a single surviving copy is enough to rebuild the rest. The panel above shows how many surfaces are available to this origin and which of them currently hold something, which is the raw material the technique needs.

Six surfaces matter in a browser, and each has a different lifetime and a different way of being cleared.

• Cookies. Tiny, sent to the server on every matching request, and the one people actually clear. Only non-HttpOnly cookies set for this origin are visible to script.
• localStorage. Roughly 5 MB, no expiry, cleared only with site data. The local storage test measures its real capacity.
• sessionStorage. Same API, but tied to one tab and gone when that tab closes, so it is the weakest of the six.
• IndexedDB. Hundreds of megabytes of structured records, and the largest place a small identifier can hide.
• CacheStorage. The cache a service worker reads from. Identifiers are usually smuggled inside cached responses rather than as keys.
• Service worker. A registered worker can intercept requests and rewrite them, so it can keep state and re-inject a value even after other stores are emptied.

The old advice, “just clear your cookies”, was written for a web where the cookie was the only store. It no longer covers everything. Clearing cookies alone leaves local storage, IndexedDB, caches and service worker registrations untouched, which is precisely the gap an evercookie is built to use.

Clearing site data is the stronger action, because it removes all of them for that origin in one step, and it is what most browsers now offer under a single heading. Private windows are stronger still: because the whole session is discarded on close, nothing needs to be cleared by hand.

The limits are worth stating plainly. A clear removes data for the origins you clear, not for every origin you have visited, and partitioned third-party storage can leave copies in contexts the main site-data clear does not reach on older builds. None of this is a reason to skip it — it is a reason not to treat it as a complete answer.

The honest boundary is origin separation. Script on this page can reach the stores belonging to this domain and nothing else, so it cannot tell you whether a shop, an advert or an analytics vendor has planted an identifier of its own. No web page can, because the browser does not expose another origin’s data to script.

There is a second limit in what the rows even mean. “Available” means the API responded to a probe write and read, not that a site has used it. “Holding data” counts entries this origin already has, which on a normal visit is usually a preference or a cached draft rather than anything sinister.

What the test does give you is the shape of the target. If five or six surfaces are open, an identifier written today could be spread widely and would need a full site-data clear to remove. If most are blocked, there are far fewer places for one to go. The cookies and storage test covers the same ground from the availability side.

The practical defences are unglamorous. Clear site data rather than just cookies, and do it for sites you do not need to stay signed in to. Use a private window for one-off browsing, since it starts empty and discards everything at the end. If you want a running check on which origins are storing what, the cookies and storage test and this page together cover both angles.

Blocking storage outright is the bluntest option and it breaks a lot: logins and preferences stop persisting, and many single-page apps fail in ways that look like bugs. It also does not address the signal that needs no storage. A fingerprint is recomputed from your device on every visit and survives every clear you can perform, which is why it is the harder problem.