ENSupercookies are tracking mechanisms that use browser state or network identifiers beyond ordinary HTTP cookies to recognize users. Some retain an identifier after cookies are deleted. Others can restore a deleted cookie from another stored copy. The term is informal and covers several techniques, so persistence depends on the mechanism and browser.
If a site still recognizes you after cleanup, first check whether you are signed in. Account information and browser signals can explain recognition without a recovered cookie. Familiar recommendations alone do not show that a deleted identifier has returned.
How Do Supercookies Work?
An ordinary cookie sits in a browser cookie store. The browser sends it with requests that match its scope and security rules. Deleting that cookie removes that particular record.
Supercookie techniques use information outside that record. The identifier might survive in another storage location or be recovered from browser state. Historical network techniques supplied an identifier through the connection instead.
Browser State and Cookie Respawning
Browsers store more than cookies. Local storage holds site data, IndexedDB stores structured records, and caches retain resources for faster loading. These systems serve normal website functions, but tracking scripts can also use them to preserve identifiers.
Unlike cookies, local storage records are not automatically attached to HTTP requests. A script must read the data and use or transmit it. Cookie blocking and script access restrictions therefore address different parts of the process.
Cookie respawning happens when another copy restores a deleted cookie:
- A tracker saves the same visitor identifier in a cookie and another accessible storage location.
- The visitor deletes the cookie but leaves the other copy.
- On a later visit, the tracker reads that copy and recreates the cookie with the previous identifier.
The process depends on the remaining copy being readable. If browser protections block access, or cleanup removes the relevant copies, that recovery path may fail.
Simply creating a new cookie on your next visit is not respawning. The important distinction is whether the previous identifier returns.
Network Identifiers
Some historical supercookies came from mobile networks rather than browser storage. In its 2016 Verizon investigation, the FCC described unique identifier headers, or UIDH, inserted into customer traffic. It also reported their use to restore cleared cookie identifiers. Deleting a browser cookie could not remove an identifier supplied by the network.
Examples of Supercookie Techniques
A cleanup action only helps if it reaches the state carrying the identifier. Browser cleanup can remove relevant local data, but it cannot remove a header added by a network.
| Technique | Where the Identifier Comes From | What Matters |
|---|---|---|
| Cache or ETag Abuse | Cached Resources or a Deliberately Assigned Resource Validator | Reuse Across Sites Depends on the Browser's Cache Boundaries |
| Respawning from Stored Data | Another Accessible Copy of a Visitor Identifier | Deleting One Cookie May Leave a Recoverable Copy |
| HSTS State Abuse | Remembered HTTPS Upgrade Rules Used to Encode Information | Browsers Have Introduced Protections Against This Abuse |
| Flash Cookies | Storage Managed by the Flash Plugin | This Is a Legacy Example |
| Carrier UIDH | A Header Inserted into Network Traffic | This Historical Mechanism Operated Outside the Cookie Store |
An ETag normally identifies a version of a resource. It helps a browser check whether its cached copy is still current. Finding an ETag in a response does not establish tracking.
Abuse can occur when a server assigns a visitor a distinctive validator rather than merely identifying shared content. If the browser later returns that value during cache validation, the server may use it to recognize the visitor.
HSTS normally tells a browser to use HTTPS for a website. In HSTS abuse, remembered rules for several controlled domains can encode a pattern. Later requests can reveal that pattern. This depends on browser behavior and protections. The security feature itself is not malicious, and disabling it broadly can weaken protection.
Adobe ended Flash Player support in December 2020. An article recommending Flash cleanup as a routine step for current browsers is relying on outdated advice.
Supercookies vs Cookies, Zombie Cookies and Fingerprinting
A long cookie lifetime, a recreated identifier, and recognition without cookies are separate behaviors.
| Term | What It Describes | Main Distinction |
|---|---|---|
| HTTP Cookie | A Record Managed by the Browser and Sent with Matching Requests | A Standard Storage Mechanism |
| Third Party Cookie | A Cookie Associated with a Site Other than the Site Currently Being Visited | Its Context Does Not Automatically Make It a Supercookie |
| Zombie Cookie | A Deleted Cookie That Gets Recreated | Describes Respawning Behavior |
| Evercookie | A Specific Implementation That Preserves Identifiers Across Multiple Storage Mechanisms | An Implementation Associated with Respawning |
| Browser Fingerprint | A Pattern Built from Browser and Device Signals | Recognition Need Not Depend on a Stored Identifier |
An ordinary cookie can remain for months if its expiration permits it. That long lifetime alone does not make it a supercookie.
A browser fingerprint can be rebuilt from signals such as browser version, screen settings, fonts, and graphics behavior. Deleting stored data does not necessarily change those signals.
Why Supercookies Raise Privacy Concerns
Deleting a tracking cookie is a deliberate attempt to remove an identifier. Silently restoring that identifier can let a tracker reconnect later visits with earlier activity. The user may see an empty cookie list immediately after cleanup and still have a recoverable copy elsewhere.
Persistent identifiers can also help connect activity across visits. Where browser boundaries allow it, shared state may support tracking across websites.
A cookie list also says little about what a tracker has already recorded. Local cleanup can remove data from the browser without removing past observations from the service that collected them.
How to Limit or Remove Supercookie Tracking
Cookie deletion, storage partitioning, and encrypted connections solve different problems. Choose the control that reaches the suspected source of recognition.
Clear the Relevant Browser Data
Chrome's cookie management controls address cookie records. Broader site data and cache cleanup may cover additional storage. Check the selected categories rather than assuming that a general cleanup label includes everything.
For a suspected local storage problem:
- Identify the affected website and browser profile.
- Check which cookies, site data, and cached resources the cleanup action covers.
- Clear the relevant data, accepting that this may remove logins or offline content.
- Revisit the site and distinguish a new identifier from a restored one.
When checking a suspected identifier, compare its value before and after cleanup. The record name alone is not enough. A site can recreate a cookie with the same name but assign a new visitor value. Matching values warrant further investigation, but they do not reveal whether recovery came from local storage or server records.
Use Browser Tracking Protections
Browser protections can block some tracking scripts before they store or recover an identifier. Firefox also partitions caches and network connections by website, limiting their reuse across sites.
Suppose the same tracker appears on two unrelated websites. Partitioning can give it a separate state context on each site, instead of one shared context. The tracker may still recognize repeat visits within an allowed context. The boundary restricts reuse across sites.
Use Separate Browsing Contexts and HTTPS
Cookie isolation separates cookie state between supported contexts. Other storage needs its own isolation boundary. Opening another tab in the same profile generally does not create an independent cookie store.
HTTPS protects data in transit against ordinary intermediary inspection and modification. It does not remove stored identifiers or prevent the receiving website from processing them.
Signing in again can connect a fresh browser session with an existing account. If the site then remembers your purchases or preferences, that may come from its account records. Repeatedly clearing the browser will not delete those records.
Supercookies FAQ
Are supercookies the same as third party cookies?
No. Third party describes the context in which a cookie is used. Supercookies is a broader, informal term for tracking beyond ordinary cookie storage. Blocking third party cookies does not automatically cover every other recognition mechanism.
Does deleting cookies remove supercookies?
It depends on what carries the identifier. Cookie deletion removes cookie records, but another accessible copy or relevant browser state may remain. Broader cleanup can address more local data, although its coverage depends on the browser.
Does private browsing stop supercookies?
Private browsing generally separates temporary browsing state from the normal profile and clears that temporary state when the session ends. It does not hide every browser signal, remove server records, or make someone who is signed in anonymous.
Can a VPN remove supercookies?
No. A VPN can protect traffic along the tunnel and change the public IP address websites see. It does not delete cookies, local storage, or cached identifiers. Websites can still recognize account information and available browser signals.
Can you test for every supercookie?
A single test cannot establish that every possible mechanism is absent. Cover Your Tracks evaluates aspects of tracking protection and browser fingerprinting. A passing result does not establish that every storage location and recognition method has been checked.
Are supercookies still relevant after Flash ended?
Yes. Flash was one storage mechanism, not the basis of every supercookie technique. Other browser state can support persistent identifiers where access remains available. Assess the current browser and mechanism rather than following old plugin cleanup instructions.
