What is an evercookie?

An evercookie is a tracking identifier deliberately stored in a dozen or more separate browser storage locations at once, so that deleting it from any one — or even most — of them doesn't actually remove it. As long as a single copy survives somewhere, a script detects the gaps and rewrites the ID back into every location you just cleared. It's often called a "zombie cookie" for exactly that reason: it keeps coming back.

Illustration representing an evercookie stored across multiple browser storage mechanisms

How it actually works

The original evercookie implementation, released by security researcher Samy Kamkar in October 2010, wrote the same identifier into as many of the following as a given browser supported:

Kamkar built it as an open-source proof of concept specifically to demonstrate how exposed this kind of tracking already was — not to secretly deploy it himself.

It wasn't hypothetical — real companies did this before evercookie even existed

The technique evercookie demonstrated had already been caught in production a year earlier. UC Berkeley researchers published a study in 2009 showing that ad tracking firms Quantcast and Clearspring were using Flash's storage capability to silently regenerate deleted HTTP cookies. Quantcast settled the resulting class action lawsuit for $2.4 million in 2010, along with a promise to stop the respawning practice — though because the affected class was functionally every internet user in the US, most of that money went to privacy organizations rather than individual payouts.

A near-identical case followed in 2011: researchers found that analytics firm KISSmetrics was using HTTP ETags to respawn deleted cookies for clients including Hulu and Spotify, both of which suspended KISSmetrics' service once the report became public. KISSmetrics settled its own class action in early 2013, paying roughly $500,000 to the plaintiffs' attorneys and agreeing to stop using ETags or other hard-to-delete storage for tracking without prior notice and an opt-out.

What's still a real threat today, and what's dead

Original vectorStatus today
Flash LSOs / Silverlight storageDead — both plugins are gone from every modern browser
Java applet persistenceDead — Java applets no longer run in any modern browser
IE userDataDead — Internet Explorer itself is discontinued
localStorage / IndexedDB respawningFully active — no plugin required, works in every current browser
ETag / HTTP cache respawningFully active — same mechanism that caught Quantcast and KISSmetrics still functions
Canvas-based PNG storageFully active, though modern canvas fingerprinting defenses can interfere with it
The lesson that survived the plugin era intact: respawning doesn't need a dozen mechanisms to work — it needs redundancy. Two or three modern, plugin-free storage locations (localStorage, IndexedDB, HTTP cache) are enough to rebuild an ID after a standard "clear cookies" action, which is why that button alone was never a real privacy guarantee.

It's a storage-based cousin to audio fingerprinting — both aim to keep identifying the same device across visits, but an evercookie stores an ID somewhere on your machine to find later, while a fingerprint computes one fresh each time from how your hardware behaves, with nothing stored at all.

How to actually clear one out

Is evercookie still a real threat today, or is it mostly historical?

Partly historical, partly still very much alive. Several of its strongest original vectors — Flash Local Shared Objects, Silverlight isolated storage, Java applet persistence — are dead because the plugins themselves are gone from modern browsers. But the underlying respawning idea (storing the same ID redundantly across localStorage, IndexedDB, HTTP cache, and ETags) works exactly the same in 2026 as it did in 2010, and doesn't need any plugin at all.

Does clearing my cookies in browser settings stop an evercookie?

No, and that's the entire point of the technique. A standard "clear cookies" action typically only touches HTTP cookies, leaving localStorage, IndexedDB, and cached ETags untouched. As long as even one storage location survives, a respawning script reads the surviving copy and rewrites it into every location you just cleared — you have to clear all storage types simultaneously for deletion to actually work.

Does private/incognito browsing block evercookie tracking?

Only within that session, and only partially. Private browsing prevents new tracking data from persisting after you close the window, but it doesn't retroactively remove an ID already respawned during the same session from mechanisms like the browser cache. It also does nothing about the original evercookie design goal of propagating an ID across different browsers via shared plugin storage like Flash — a threat that's mostly moot today since those plugins are gone, but was a real limitation of private browsing's isolation model at the time.

Is "evercookie" the same thing as a Verizon-style "supercookie"?

No — different mechanism, similar nickname. Verizon's UIDH ("Unique Identifier Header," widely reported as a supercookie) was a tracking string carriers inserted directly into your mobile traffic at the network level, invisible to any browser setting and impossible to delete client-side — it led to a $1.35 million FCC settlement in 2016. An evercookie operates entirely client-side, inside your browser's own storage mechanisms, with no carrier involvement required.

Is using evercookie-style tracking illegal?

It depends on jurisdiction and disclosure, not the technique itself. Both real-world cases on this page were pursued as violations of specific laws — wiretap statutes and the Video Privacy Protection Act — rather than a law against "evercookies" as such. KISSmetrics's 2013 settlement required the company to stop the practice without prior notice and user choice specifically — meaning the core legal problem was undisclosed tracking that ignored a user's explicit deletion choice, not the underlying code.