A supercookie is a tracking identifier that is stored or reconstructed outside the regular cookie store of a browser, for example in caches, browser security state or network headers, so that it persists after users clear their cookies or switch to private modes. In tracking, the term describes a family of techniques rather than a single file format; what unites them is that ordinary privacy controls do not see or remove the identifier.
The word also has a narrower, older meaning: a cookie set on a public suffix such as a top-level domain, which would be readable by every site beneath it. Browsers block that variant with the Public Suffix List, so most current discussion of supercookies refers to the persistent, hard-to-delete tracking techniques.
How a supercookie stores an identifier
Every supercookie abuses a storage mechanism that was designed for performance, security or compatibility, not for identification. The tracker writes a unique value into that mechanism on the first visit and reads it back on later visits, often from a different site that embeds the same third-party resource. Because the mechanism is not labeled as a cookie, clearing cookies leaves it intact.
Some techniques store the identifier directly, for example in an ETag that the server assigns to a cached image. Others encode it in bits: a tracker can force a browser to remember HSTS policies for, say, 32 subdomains, then read which ones upgrade to HTTPS to recover a 32-bit number. The second approach is harder to detect, because no single storage entry looks like an identifier.
The table below lists the main storage vectors that have been used for supercookies and how browsers have responded.
| Vector | How the identifier is kept | Current status |
|---|---|---|
| Flash local shared objects | Plugin storage outside the browser | Obsolete since Flash support ended |
| ETag and cache entries | Validator header returned with cached files | Limited by partitioned HTTP caches |
| HSTS pinning | HTTPS upgrade flags across many subdomains | Mitigated by HSTS limits and partitioning |
| Favicon cache | Pattern of cached icons across paths | Mitigated in major browsers |
| Header enrichment | Identifier injected by a mobile network | Restricted by regulators and HTTPS |
| Evercookie-style respawning | Copies in many stores restore each other | Weakened by storage partitioning |
Network-level supercookies
A distinct class of supercookie is inserted by an internet service provider rather than by a website. In header enrichment, a mobile carrier adds a unique identifier header to unencrypted HTTP requests passing through its network. Every site the subscriber visited over plain HTTP could read it, and the user had no browser setting to remove it.
In the mid-2010s a large United States carrier was penalized by the Federal Communications Commission for injecting such headers without adequate disclosure and opt-out. The widespread move to HTTPS everywhere has largely closed this channel, because a carrier cannot modify encrypted requests without breaking them, but the case remains the reference example of a supercookie that users cannot control at all.
Supercookie compared with related tracking techniques
Supercookies sit between classic third-party cookies and device fingerprinting. They store state, like cookies, but in places users cannot easily inspect, whereas fingerprinting stores nothing and infers identity from device characteristics.
| Technique | Stores state on device | Cleared by deleting cookies | Main defense |
|---|---|---|---|
| Third-party cookie | Yes, in the cookie jar | Yes | Third-party cookie blocking |
| Supercookie | Yes, in caches or security state | Usually no | State and cache partitioning |
| Device fingerprinting | No | Not applicable | Reducing and randomizing exposed signals |
| Bounce tracking | Yes, as first-party cookies | Yes | Redirect tracking detection |
| CNAME cloaking | Yes, as first-party cookies | Yes | DNS-aware tracker blocking |
The practical difference is persistence against user action. Bounce tracking and CNAME cloaking disguise third-party tracking as first-party activity, but their cookies still disappear when the user clears site data. A supercookie is designed precisely to outlive that action.
Browser defenses against supercookies
The decisive countermeasure is state partitioning: browsers key caches and other storage by the top-level site as well as by the resource origin. A tracker embedded on two different sites then sees two separate caches and cannot link the visits. Safari’s Intelligent Tracking Prevention, Firefox’s Enhanced Tracking Protection and current versions of Chrome all partition the HTTP cache and much of the related state.
| Defense | What it changes | Effect on supercookies |
|---|---|---|
| HTTP cache partitioning | Cache keyed by top-level site | Blocks cross-site ETag and cache tracking |
| Network state partitioning | Connections and DNS keyed per site | Removes timing-based linkage |
| Clear all site data | Wipes every store for a site | Defeats respawning from leftover copies |
| HTTPS by default | Encrypts requests end to end | Blocks carrier header injection |
| Tracker blocker lists | Stop known tracking scripts loading | Prevents the write in the first place |
Partitioning has a cost: shared resources such as common fonts or script libraries are no longer reused across sites, which reduces cache efficiency. Browser vendors judged that this performance trade-off was acceptable to close a whole class of tracking.
Legal status and detection limits
In the European Union, a supercookie is still storage on terminal equipment under the ePrivacy Directive and requires prior consent like any non-essential cookie. Using it to recreate an identifier the user deleted is widely regarded as bad faith, because it overrides an explicit privacy choice, and regulators have treated respawning as an aggravating factor.
- Supercookies are hard to audit, because cookie scanners do not inspect caches or HSTS state.
- Detection requires comparing network traces across sites and sessions.
- Partitioning stops cross-site linkage, but a single site can still track repeat visits.
- Private browsing helps only when it isolates every storage type, not just cookies.
Explained without jargon
A normal cookie is like a name tag a website pins on you. You can take it off by clearing your cookies. A supercookie is a name tag hidden somewhere you would not think to look, such as inside the browser’s memory of pictures it already downloaded.
Because it is hidden, clearing cookies does not remove it, and the website can still recognize you. Modern browsers fight this by giving every website its own separate memory, so a hidden tag left on one site cannot be read on another.
A typical use case
A privacy researcher tests whether a news site still recognizes returning readers who clear their cookies. She loads the site, deletes all cookies, reloads it and compares the outgoing requests. One request to an embedded third-party image carries an If-None-Match header with the same value on every visit, even after cookie deletion. The image server is using its ETag as a supercookie.
She repeats the test in a current browser with partitioned caching. The value now differs between the news site and a second site embedding the same image, so cross-site linkage fails. Only after she uses the browser function that clears all site data, including the cache, does the identifier disappear on the original site as well. Her report recommends that the publisher remove the tracking vendor, because the technique required consent that was never requested.