What is a supercookie, and why does clearing cookies fail?

"Clear cookies" is the reflexive answer to almost every privacy worry, and for a plain HTTP cookie it works fine. A supercookie is built specifically to survive that click. It isn't one technology — it's an umbrella term for any identifier that lives somewhere your browser's cookie jar doesn't reach, from a cached image to a header your own internet provider adds to your traffic before it ever gets to your browser.

What actually makes a cookie "super"

A standard HTTP cookie is a small text value your browser stores and sends back to a site on request, and it's fully under your control — delete it, block it, or set it to expire, and it's gone. A supercookie does one or both of two things a regular cookie can't: it hides in a storage location outside the cookie jar, or it regenerates itself after you delete it by pulling a copy from wherever else it was also stored. Some go further and sit entirely outside your device, which is the case that surprises people most and the one covered further down this page.

Why "clear cookies" doesn't touch it

Your browser's "clear cookies" option is scoped narrowly, by design — it empties the cookie store and nothing else. Meanwhile a modern browser exposes over a dozen separate storage systems to any website that wants to use them: the HTTP cache, localStorage, IndexedDB, Service Worker caches, the window.name property, and the browser's own internal record of which sites you've visited over HTTPS (its HSTS security-policy list). A site only needs to write the same identifier into a couple of these to outlive a cookie clear, and several of these stores are covered by the browser's "clear site data" setting rather than its cookie setting specifically — a distinction most people never notice because the two options sit in the same settings panel.

The client-side techniques

ETag and cache-based tracking

Every cached file your browser stores — an image, a script, a stylesheet — can carry an ETag header, a value the server uses to check whether its cached copy is still current. Nothing stops a server from generating a unique ETag per visitor and reading it back on every subsequent request for that same file, turning an ordinary caching mechanism into an identifier that survives a cookie deletion entirely. Hulu was documented using exactly this technique in the early 2010s, rebuilding a user's tracking ID from a cached file's ETag after the cookie holding that ID had been deleted.

HSTS pinning: encoding an ID in your own security history

This one is the least intuitive and arguably the cleverest. A tracker registers a large block of subdomains — say, 32 of them — and treats each one as a single bit. To write a value, it silently loads a chosen subset of those subdomains in a hidden request, and only the ones it wants set to "1" get instructed to enforce HTTPS via an HSTS header. Your browser dutifully records which of those subdomains now require HTTPS, exactly as HSTS is supposed to work. To read the value back later, the tracker loads all 32 subdomains again over plain HTTP and checks which ones your browser silently upgraded to HTTPS on its own — those are the bits that were set. Nothing here is a bug in HSTS; it's a creative abuse of a security feature working exactly as specified, which is precisely why it's so hard to patch without weakening HSTS itself.

Evercookie: the proof-of-concept that combined everything

In 2010, researcher Samy Kamkar released Evercookie, an open-source script built to demonstrate exactly how durable a determined tracker could make an identifier by writing the same value into every storage mechanism a browser exposed at once — cookies, Flash local shared objects, Silverlight storage, cached PNG pixel data, HSTS pinning, and more. Delete any one of them, and Evercookie simply reads a surviving copy from another location and rewrites the deleted one. It was built as a warning, not a product, but a top-secret document leaked by Edward Snowden in 2013 showed an intelligence agency had studied the same respawning approach to help de-anonymize Tor users — a reminder that the technique isn't just an ad-tech curiosity.

UID smuggling: the modern workaround

Most of the techniques above have gotten considerably weaker since browsers started partitioning storage by site. Chrome partitioned its HTTP cache by top-level origin starting in 2020, and extended partitioning to most other storage and communication APIs for third-party content from Chrome 115 onward; Firefox (Total Cookie Protection), Safari (Intelligent Tracking Prevention), and Brave already did the same earlier. Partitioning means a script embedded on siteA.com and the same script embedded on siteB.com now get separate, isolated storage buckets instead of a shared one — which quietly defeats the kind of cross-site tracking used for targeted advertising without the user doing anything.

The current workaround researchers have documented is UID smuggling: instead of storing an identifier in the browser at all, a tracker appends it directly to the URL as the user is redirected through one or more tracking domains on the way to their actual destination, then reads it back out of that URL server-side. No partitioned storage gets touched because no client-side storage is used in the first place — it's a reminder that browser-level fixes close specific doors rather than the whole building.

The network-level case: Verizon's UIDH

Every technique above at least runs on your device. In 2012, Verizon Wireless began inserting a Unique Identifier Header (UIDH) into its subscribers' unencrypted web traffic at the network level — a header added by Verizon's own infrastructure as a request passed through its network, not something stored in the subscriber's browser at all. Because it never touched the device, no combination of clearing cookies, cache, or history could remove it — it would simply reappear on the next request, reinserted by the network itself.

Verizon didn't disclose the practice until October 2014, nearly two years after it began, and only added an opt-out after updating its privacy policy in March 2015. The FCC opened an investigation and, in March 2016, reached a settlement requiring Verizon to pay a $1.35 million fine and obtain opt-in consent before sharing UIDH data with third parties going forward. The investigation also found that at least one advertising partner had used the UIDH to rebuild cookie IDs that users had deliberately deleted — pairing a network-level identifier with a client-side one to defeat a privacy choice on both fronts at once.

What actually removes or blocks a supercookie

• Clear more than cookies. Use "all time" range and include cache and site data, not just the cookie checkbox — this alone removes ETag-based tracking and most Evercookie-style respawning.
• Clear your HSTS state directly. Chrome exposes this at chrome://net-internals/#hsts under "Delete domain security policies" — most people never know this screen exists, and it's the only way to fully clear HSTS-pinning-based identifiers.
• Use a browser that partitions storage by default. Firefox's Total Cookie Protection, Safari's Intelligent Tracking Prevention, and Brave all isolate third-party storage per site out of the box, which blunts cross-site cache and storage tracking without any manual cleanup.
• Encrypt the connection itself. A VPN or consistent HTTPS use closes the network-injection door entirely — there's no client-side setting that substitutes for this, since the identifier in that case is never on your device to begin with.
• Separate sensitive browsing into its own profile or container. A supercookie tied to one browser profile doesn't cross into a second, isolated profile — a simpler and more durable fix than trying to selectively clear one tracker's data out of a shared profile.

None of these is a single silver bullet, which is the honest takeaway: a supercookie is defined by using more than one storage mechanism at once specifically so that no single cleanup step catches all of it. Test what your own setup currently exposes with our IP leak test, and pair it with a VPN configured the way our best VPNs guide recommends if network-level tracking is your main concern.