Cookies are only one of several places a site can store an identifier. Here is every storage a page can reach, and what clearing your browsing data really removes.
On this page
Clear your cookies, and the site still knows you on your next visit. That is the whole problem in one line.
When people talk about clearing their browsing data, they usually mean deleting cookies. That mental model is out of date. A modern page has half a dozen separate storage systems it can write to, each with its own rules and its own survival characteristics. Understanding the full list — and the trick known as the evercookie, which uses several at once — is the only way to know what a clear actually clears.
Every store a page can reach
Each of these is a place a site can leave data on your device:
cookies— small key-value pairs sent back to the server with every matching request, and the classic tracking container.localStorage— a key-value store that persists indefinitely until something removes it, never sent to the server automatically, so scripts read it and forward what they need.sessionStorage— the same idea as localStorage, but wiped when the tab closes.IndexedDB— a full database in the browser, capable of holding large structured records, not just short strings.Cache Storage— space meant for assets, which can also hold data a script retrieves later.service workers— background scripts that can intercept requests and persist between visits, acting as a coordinator for everything above.
Check which of these your browser actually allows with the local storage test, which writes and reads a value to confirm the store is working.
Why browsers keep so many
Each store was built for a legitimate purpose. Cookies carry session state to the server. localStorage keeps preferences on the client without a round trip. IndexedDB lets web applications work offline and hold real data rather than small strings. Cache Storage makes repeat visits fast.
The tracking value is a side effect of those features, not their intent. But a store that survives, and that only your browser can see, is exactly what a tracker wants. A single identifier written into localStorage is invisible in the page, never appears in a network request to a third party, and sits there until something deliberately deletes it.
How the newer stores differ from cookies
The newer stores differ from cookies in ways that matter for both tracking and defence.
| Store | Sent to server automatically | Typical lifetime |
|---|---|---|
| Cookies | Yes | Set per cookie |
| localStorage | No | Until removed |
| sessionStorage | No | Until tab closes |
| IndexedDB | No | Until removed |
| Cache Storage | No | Until removed |
| Store | Survives a narrow “clear cookies” |
|---|---|
| Cookies | No |
| localStorage | Sometimes |
| sessionStorage | No |
| IndexedDB | Sometimes |
| Cache Storage | Sometimes |
The second table is the important one. In many browsers “clear cookies” and “clear site data” are different actions, and only the broader one touches the newer stores. Select the narrow option and you can leave a durable identifier behind.
The evercookie repair loop
An evercookie is not a special kind of object. It is a technique: write the same identifier into as many stores as possible, and treat them as redundant copies of one another. The name comes from the idea that the cookie keeps coming back.
The mechanism is a repair loop. When a script loads and finds a store that still holds the identifier, it copies that value back into every other store that has since been emptied. Delete your cookies, and the next visit reads the value from localStorage, rewrites the cookie, and the identifier is whole again. To fully remove it you would have to find and clear every copy in the same pass, which is difficult if you do not know where they all are. The evercookie test demonstrates the loop by writing across multiple stores and showing which ones survive.
What IndexedDB adds
IndexedDB deserves separate attention because of its size. Cookies are tiny and localStorage is small; a database can hold a great deal. That makes it suitable for storing a rich record — not just an identifier but usage details — entirely client-side, where it can be read back and forwarded at the site’s convenience. The IndexedDB test shows whether a database can be opened and written to in your browser.
What clearing your data does
A full “clear site data” or “clear browsing data, all time” action removes cookies, localStorage, IndexedDB and cache entries for the sites it covers. That is effective against evercookies, because every copy is taken at once and there is nothing left to repair from.
What it does not do is prevent recreation. The moment you return, the site can write fresh identifiers, and if it can recognise you by other means it can link the new store to the old identity. That is the join between storage and browser fingerprinting, and it is why clearing data alone is never the complete answer. The wider comparison is worth reading in cookies versus fingerprinting — the point being that storage is the visible layer, and the fingerprint is the layer beneath it.
What survives a clear
Run these two rather than trusting your assumptions. Clear your browsing data, then run the evercookie test immediately afterwards to see how much can be written back. Then run the IndexedDB test to confirm whether a database can be reopened. What survives a clear tells you more than any explanation of what should.