A zombie cookie is a tracking cookie that comes back after you delete it. It hides backup copies of its ID outside your browser's normal cookie storage, in places like Flash storage, HTML5 local storage, or the browser cache. It is built to resist deletion.
What Is a Zombie Cookie?
Zombie cookie is a behavior, not a product or file format. The term describes any tracking cookie engineered to survive the deletion a privacy-conscious user thinks worked. Wikipedia's zombie cookie entry documents the technique in detail. The name comes from what it does: you kill it, and it comes back.
The mechanism sets it apart from an ordinary cookie. A regular HTTP cookie holds one identifier in one place, so deleting it removes the tracker completely. A zombie cookie writes that same identifier into several hiding spots at once, planted by third-party cookies and advertising scripts. Deleting the visible copy leaves the tracker intact elsewhere.
A cookie only earns the "zombie" label when it demonstrably regenerates after a user-initiated deletion. Tracking across sites alone does not qualify. The respawning behavior is the defining trait.
How Do Zombie Cookies Work? (How They Respawn)
A zombie cookie respawns because the tracker never relies on a single storage location. It writes the same ID into a normal cookie and several hidden backup locations at once. Deleting one copy leaves the rest to rebuild it.
The respawn cycle runs in three steps:
- A tracking script writes your ID as a standard cookie. It quietly copies the same ID into hidden locations, such as Flash storage, local storage, or browser cache.
- You delete the visible cookie through your browser's normal privacy settings.
- On your next visit, a script checks every hidden location, finds a surviving copy, and rewrites the deleted cookie with the same ID.
Deleting one copy is not enough. One survivor rebuilds the rest, so a zombie cookie behaves like one organism spread across several storage systems, not one file you can remove.
Where Zombie Cookies Hide Their Backups
Zombie cookies hide backup IDs across a documented set of storage locations. Most are browser or plugin features built for legitimate use, not tracking. Wikipedia's zombie cookie entry lists these vectors:
- Flash Local Shared Objects (LSOs): the classic backup vector, now legacy since Flash's end of life
- HTML5 local storage and session storage: persistent key-value storage built into modern browsers
- HTML5 IndexedDB: a structured, larger-capacity browser database
- HTTP ETags: cache-validation tokens that double as a stable identifier
- Browser cache: cached files that carry a hidden ID inside them
- HSTS flags: security settings that can encode bits of an identifier
- Canvas and PNG-pixel storage: an ID hidden in pixel color values, the same trick used in browser fingerprinting
- Silverlight isolated storage and Internet Explorer userData: legacy plugin and browser storage from older systems
This is the same vector set Samy Kamkar's evercookie project demonstrated in 2010. It chained 17 storage locations into a single self-healing identifier.
How the Respawn Actually Happens
A small JavaScript routine drives the actual regeneration. It reads every storage location the tracker planted and compares the IDs it finds. It then restores whichever copies are missing, so your profile survives as long as one copy does.
Trackers often add cookie syncing on top of this. Once the ID rebuilds, the script shares it with partner ad networks. Multiple companies then stay aligned on the same identity, even after you reset it.
Zombie Cookies vs Supercookies vs Evercookies vs Flash Cookies
These four terms get used interchangeably online, but they describe different things. One is a behavior, one is a storage location, one is a specific implementation, and one is a broader category.
| Term | What it actually is | Key trait |
|---|---|---|
| Zombie cookie | The self-respawning behavior: any cookie engineered to regenerate after deletion | Defined by what it does, not where it lives |
| Supercookie | A tracker that lives outside normal browser cookie storage | Includes ISP-injected network supercookies (UIDH) and cache or HSTS-based supercookies |
| Evercookie | Samy Kamkar's open-source proof-of-concept that chains roughly 17 storage vectors | A specific, named implementation, not a category |
| Flash cookie (LSO) | One specific storage location, now legacy since Flash's 2020 end of life | Often used as one backup vector among several, not the whole mechanism |
The overlap is real. An evercookie is a zombie cookie technique in practice, and a zombie cookie is frequently called a supercookie in casual use. The precise distinction is storage location versus behavior versus implementation. Supercookie describes where a tracker lives, zombie cookie describes what it does, and evercookie names one specific tool that does it. For the full map, see every type of cookie tracking uses today.
Are Zombie Cookies the Same as Persistent Cookies? (A Common Mix-Up)
No. A persistent cookie is a normal cookie with a future expiration date, so it survives until it expires or you delete it. It does not come back once deleted. A zombie cookie actively regenerates itself.
Several cookie glossaries blur this distinction, describing zombie cookies as simply a type of persistent cookie. That description misses the defining trait: deleting a persistent cookie removes it permanently, exactly as intended. Deleting a zombie cookie does not, because hidden backup copies rebuild it on your next visit. The difference is "long-lived and deletable" versus "self-resurrecting." A session cookie expires when you close your browser and carries no respawn mechanism.
Why Are Zombie Cookies a Problem?
Zombie cookies undermine the most basic privacy action a user can take: deleting their cookies. That failure creates a cascade of downstream harms for anyone being tracked.
- They defeat opting out. Clearing cookies or resetting a browser is the standard advice for stopping tracking, and zombie cookies make that advice false for the user who follows it.
- They enable persistent cross-site tracking and behavioral advertising without renewed consent or awareness, since the user believes they started fresh.
- They are hard to even detect, because the backup copies sit in storage locations most users never inspect, unlike a visible cookie list.
- They erode trust deliberately, since the entire mechanism exists to hide tracking from the person being tracked, not to accidentally persist.
The emotional core is simple: a user does the responsible thing and clears their cookies, and the same advertiser keeps following them anyway. Browser fingerprinting has since emerged as a cookieless successor built on the same motive, identifying users without storing anything on their device at all.
Real Zombie Cookie Cases: Verizon, Turn, and KISSmetrics
Zombie cookies are not a theoretical risk. Regulators and researchers have documented specific companies using them at scale, with real financial and legal consequences.
- Verizon and Turn (2015). ProPublica revealed that ad firm Turn used a unique identifier Verizon injected into its subscribers' mobile traffic, called a UIDH, to respawn tracking cookies users had deleted. Verizon's UIDH practice drew a $1.35 million FCC consent decree in March 2016, along with a requirement to let subscribers opt in or out. Verizon later merged the same UIDH tracking with AOL's ad network, according to a ProPublica follow-up later that year.
- KISSmetrics (2011 to 2012). The analytics firm used HTTP cookies, Flash cookies, and ETags to respawn IDs, deployed through Hulu and Spotify. After the practice was publicly disclosed in mid-2011, both companies suspended it, and KISSmetrics settled the resulting lawsuit for more than $500,000 in October 2012.
- Evercookie (2010). Researcher Samy Kamkar published evercookie, an open-source proof-of-concept chaining roughly 17 storage locations, which became the reference implementation for the entire technique. Leaked 2013 NSA documents later showed evercookie-style tracking used in an attempt to unmask Tor users. The Tor Project says its Tor Browser Bundle and Tails operating system defend against this.
How to Get Rid of Zombie Cookies
Clearing your browser's normal cookie list is not enough on its own. You also have to clear the other storage locations a zombie cookie hides in, or a single surviving copy rebuilds everything you just deleted.
- Clear cookies and cached files for "all time" in your browser's privacy settings, not just the default recent-history window. This step covers the normal way to delete cookies in your browser, but a zombie cookie needs more than that.
- Clear the other storage locations. Open developer tools (F12), go to the Application or Storage panel, and delete Local Storage, Session Storage, and IndexedDB for the offending sites.
- Clear Flash Local Shared Objects only if you still run software that uses Flash. Flash reached end of life in December 2020, so this step matters far less than it once did.
- Use a dedicated cleanup tool or a "delete cookies on close" browser extension so the same trackers cannot quietly re-accumulate after you clean up.
There is no need to wipe your entire browser profile. Targeted clearing of the storage locations above breaks the respawn cycle. It removes every copy at once, instead of the one copy your browser's basic delete button touches.
How to Block Zombie Cookies Before They Take Hold
Blocking zombie cookies before they establish a foothold is more reliable than removing them afterward, since prevention does not depend on finding every hidden copy.
- Block third-party cookies and enable cross-site tracking protection in your browser's privacy settings.
- Use a browser built for storage isolation, such as Firefox with cache-partitioning supercookie protections, Brave, or Safari's Intelligent Tracking Prevention, all of which partition storage so a tracker on one site cannot reuse data planted by another.
- Install a dedicated tracker blocker, such as uBlock Origin, Privacy Badger, or Ghostery, which stop many zombie-cookie scripts from writing to backup storage in the first place.
- Do not rely on incognito or private mode alone. Cache-based and favicon-based supercookies can survive private browsing, because they exploit storage that private mode does not fully isolate.
A VPN blunts one specific vector: ISP-level network supercookies like Verizon's old UIDH injection. It does nothing about in-browser zombie cookies planted by the sites you visit. Treat it as a partial measure, not a replacement for understanding how cookies track you at the browser level. Even amid the third-party cookie phase-out, respawning tracking persists on any site that still runs one.
Are Zombie Cookies Legal? What They Mean for Website Owners
A cookie that respawns after a visitor deletes it or opts out cannot meet valid-consent and withdrawal rules. GDPR, the ePrivacy Directive, and CCPA and CPRA all demand them. That exposes a site to real regulatory and legal risk.
Each regime fails a respawning tracker for a specific reason, not one blanket verdict. Valid consent must be freely given, specific, informed, and as easy to withdraw as to give:
- GDPR Article 7(3) requires that consent be as easy to withdraw as it is to give. A tracker that rebuilds itself after a user withdraws consent cannot honor that withdrawal, by definition.
- The ePrivacy Directive, Article 5(3), requires prior consent before storing or accessing information on a user's device at all, and the rule is technology-neutral. That means Flash storage, HTML5 storage, and ETags fall inside its scope exactly as much as an ordinary cookie does.
- CCPA and CPRA give California consumers a right to opt out of the sale or sharing of their personal information. A tracker that reinstates itself after a consumer opts out defeats that right directly.
Most site owners never deliberately install a zombie cookie. A third-party ad or analytics script can introduce a respawning tracker without the owner's knowledge, and the owner still carries the liability for it. The practical fix is knowing exactly what runs on your site. Load trackers only after cookie consent that a visitor can genuinely revoke, as part of broader cookie compliance for any site owner.
How Consently Helps You Avoid Hidden, Non-Compliant Trackers
Consently scans every site it protects for cookies and trackers. It then blocks anything non-essential until a visitor consents, so nothing resembling a zombie cookie fires without permission.
Manually auditing a site for hidden or respawning trackers leaves exactly the blind spot that lets a third-party script introduce non-compliant tracking unnoticed. Consently's Auto Scanning crawls your site on install, detects every cookie present, and updates the banner's cookie categories automatically.
Alongside scanning, Consently blocks non-essential cookies, scripts, and iframes before a visitor consents, and keeps a consent log for every visitor decision. That log is a deletable, revocable record, the direct opposite of a tracker engineered to survive deletion.
A compliant consent management platform only ever sets cookies a visitor consented to, and only ever keeps them as long as that consent lasts. Try Consently free to scan your own site for hidden trackers before a respawning cookie becomes your liability.
FAQs
What is a zombie cookie in simple terms?
A zombie cookie is a tracking cookie that comes back after you delete it. It hides backup copies of itself in places your browser's normal cookie deletion does not reach, then rebuilds itself from those copies.
How do I know if I have zombie cookies?
The clearest sign is a cookie, login, or ad preference that reappears immediately after you clear it. Most cases of reappearing cookies are actually browser sync or a "clear on close" setting, not a genuine zombie cookie. Check those settings first.
Does clearing my browser history remove zombie cookies?
No. Browser history and cookie storage are separate systems entirely. You must also clear local storage, IndexedDB, and cached files, since a zombie cookie's backup copies live in those locations, not in your history.
Are zombie cookies illegal?
A tracker that respawns after a user deletes it or opts out fails specific legal requirements rather than one universal ban. GDPR Article 7(3) requires that consent be as easy to withdraw as to give, which a self-restoring tracker cannot honor. The ePrivacy Directive's Article 5(3) requires prior consent before any storage on a device, technology-neutral, so hidden backup stores are covered. CCPA and CPRA give consumers an opt-out right that respawning defeats directly. Verizon's UIDH supercookie practice, which respawned deleted tracking IDs, drew a $1.35 million FCC consent decree in March 2016.
Is a zombie cookie the same as a supercookie?
They overlap but are not identical. Zombie cookie describes the self-respawning behavior; supercookie describes a tracker that lives outside normal browser cookie storage, including ISP-injected network supercookies and cache-based supercookies.
Do zombie cookies still exist now that Flash is gone?
Yes. Flash Local Shared Objects were one backup vector, and Flash reached its end of life in December 2020. HTML5 local storage, ETags, browser cache, and HSTS flags still enable the same respawn behavior without any Flash dependency.
Can incognito mode stop zombie cookies?
Not reliably. Cache-based and favicon-based supercookies can survive incognito or private browsing, because they exploit storage that private mode does not fully isolate. Isolated or private storage helps against some vectors, but it is not an absolute defense.
Why do my cookies keep coming back after I delete them?
Usually a browser "clear on close" setting, an account sync across devices, or a bug resets the cookie, not a true zombie cookie. Genuine zombie cookies are rarer and specifically respawn from hidden storage outside your browser's normal cookie jar.
