Skip to main content
Cookie Gate
Commerce Security logo, "All 12 PCI DSS Requirements in Plain English," "Get it now for free," "Complete Survival Guide" and a button toclick to get it
Category: Tracking Technologies

Zombie Cookies

Also known as: Zombie Cookie
Simply put

A zombie cookie is a tracking cookie that automatically comes back even after you delete it from your browser. It works by storing backup copies of its data in other places on your device, so it can rebuild itself once you clear your cookies. This makes zombie cookies unusually difficult to remove and raises concerns because users cannot easily stop the tracking.

Formal definition

A zombie cookie is a tracking mechanism that persists by regenerating itself after a user clears or deletes cookies from their browser. Regeneration is typically achieved by redundantly storing identifying data in multiple locations outside the standard cookie store (for example in local storage or other client-side or server-assisted persistence mechanisms), from which the cookie can be re-created. Because such techniques operate by writing to and reading from a user's terminal equipment, they generally fall within the scope of consent obligations under the ePrivacy regime in the EU/UK where they store or access information on a user's device, and any resulting processing of personal data engages the GDPR; a covert regeneration design that circumvents a user's deletion of cookies is difficult to reconcile with the requirements for valid, informed consent and with users' ability to withdraw it. The precise regulatory treatment depends on facts not addressed by this definition, including the specific storage technique used, jurisdiction, and applicable data protection authority guidance.

Why it matters

Zombie cookies matter because they undermine one of the most basic controls users have over online tracking: the ability to delete cookies from their browser. When a tracking identifier silently regenerates itself after a user has cleared it, the user's clear expression of a preference is effectively ignored. In the EU and UK, this is difficult to reconcile with the ePrivacy requirement to obtain valid consent before storing or accessing information on a user's device, and with the GDPR principle that consent must be as easy to withdraw as to give. A mechanism designed to persist through deletion works against both.

Beyond the consent question, zombie cookies raise transparency concerns. Because the regeneration relies on backup copies of data held in locations outside the standard cookie store, users are generally unaware that clearing their cookies has not actually stopped the tracking. This can conflict with the requirement that consent be informed, since users cannot meaningfully understand or control a process that is hidden from them. Organizations that deploy or permit such techniques, whether directly or through third-party scripts and SDKs, may find it hard to demonstrate a lawful basis for the resulting storage and processing.

The precise regulatory exposure depends on facts not settled by the concept alone, including the specific storage technique used, the jurisdiction, and the guidance of the relevant data protection authority. Requirements also differ across regimes: EU and UK rules generally rest on prior opt-in consent, while several US state privacy frameworks rely more heavily on opt-out mechanisms. This entry does not attempt to resolve how any particular authority would treat a given implementation.

Who it's relevant to

Privacy officers and data protection professionals
Zombie cookies present a direct challenge to demonstrating valid, informed consent and honoring withdrawal. Where regeneration circumvents a user's deletion of cookies, it becomes difficult to show that storage and access to information on the device rest on a lawful basis. Privacy teams should assess whether any tracking on their properties persists through cookie deletion, including through third-party scripts.
Legal counsel and compliance teams
Counsel evaluating tracking practices need to distinguish the ePrivacy obligations that govern placing and accessing information on a device from the GDPR obligations that govern any resulting processing of personal data. The regulatory treatment of a given zombie cookie implementation depends on facts such as the storage technique, jurisdiction, and applicable authority guidance, and requirements differ between EU and UK opt-in regimes and US state opt-out frameworks.
Web developers and engineers
Developers are typically the ones who implement or integrate tracking scripts, local storage, and SDKs that could enable regeneration. Understanding how backup copies of identifiers can rebuild a deleted cookie is essential to avoid deploying, often inadvertently, mechanisms that persist against user deletion and that are hard to reconcile with consent requirements.
Marketing and analytics compliance teams
Teams that rely on tracking for measurement or advertising should be aware that persistence techniques which survive cookie deletion carry heightened compliance risk. Confirming that vendors and tags respect user deletion and consent choices supports defensible use of tracking data.

Inside Zombie Cookies

Respawning mechanism
The defining characteristic of a zombie cookie is its ability to be automatically recreated after a user deletes it. This typically relies on a copy of the identifier being stored elsewhere on the device, which is then used to restore the deleted cookie on a subsequent visit.
Redundant storage locations
Zombie cookies commonly persist identifiers across multiple storage vectors beyond conventional HTTP cookies, such as HTML5 local storage, IndexedDB, Etags, or historically Flash Local Shared Objects. Because these are functionally similar tracking technologies, they generally fall within the same ePrivacy and consent rules as cookies even though they are not literally cookies.
Persistent identifier
The value that is preserved and respawned typically functions as a unique or pseudonymous identifier tied to a user or device. Where such an identifier relates to an identifiable individual, its processing generally constitutes processing of personal data under the GDPR, in addition to the ePrivacy rules governing access to and storage on the device.
Circumvention of user choice
Zombie cookies undermine the user's ability to exercise control by making deletion or withdrawal of consent ineffective. This conflicts with the general expectation, particularly in EU jurisdictions, that users can refuse or withdraw consent as easily as they gave it.

Common questions

Answers to the questions practitioners most commonly ask about Zombie Cookies.

Are zombie cookies just a type of ordinary cookie that keeps coming back?
Not exactly. Zombie cookies describe cookies that respawn or reconstruct themselves after a user deletes them, typically by drawing on backup copies stored outside the ordinary cookie store. That backup data is often held in technologies that are not literally cookies, such as HTML5 local storage, Flash Local Shared Objects, ETags, or values derived through fingerprinting techniques. So a zombie cookie is better understood as a persistence mechanism spanning several storage locations than as a single cookie that reappears. In most EU jurisdictions, the same ePrivacy rules on storing and accessing information on a user's device generally apply to these non-cookie technologies as well.
If a user deleted the cookie, does that mean we no longer need their consent to recreate it?
No. Deleting a cookie is not the same as a fresh legal basis to store or access information again. Under the ePrivacy Directive as implemented across most EU jurisdictions, storing or accessing information on a user's device generally requires prior consent unless a specific exemption applies, and reconstructing a previously deleted identifier does not benefit from an implied permission. Where personal data is processed as a result, the GDPR's separate requirements also apply. Respawning an identifier that a user actively removed may in fact cut against the requirement that consent be freely given and revocable, and it can undermine the user's ability to withdraw consent as easily as they gave it. This entry does not resolve how every data protection authority would characterize a specific respawning setup, which depends on the facts.
How can we detect whether zombie cookie behavior exists on our own site or in third-party tags?
A practical approach is to audit persistence across storage locations rather than the cookie jar alone. Teams typically clear cookies and then re-inspect the browser after continued use to see whether identifiers reappear, while also examining local storage, IndexedDB, any legacy Flash storage, ETag and cache-based tracking, and script behavior in third-party SDKs and tags. Because respawning is frequently introduced by vendors, reviewing the tags and SDKs loaded through your tag manager and comparing behavior before and after consent withdrawal is often useful. Findings should be documented, but note that a technical audit identifies behavior and does not by itself determine the legal characterization, which requires separate legal judgment.
How should a consent management platform handle non-cookie storage so that identifiers do not respawn?
A CMP can only govern what it is configured to control. To reduce respawning risk, the CMP and surrounding tag governance generally need to gate not just cookies but also local storage, session storage, Flash objects where present, and vendor SDKs behind the relevant consent state, and to ensure that withdrawal actually clears or blocks these backups rather than only the cookie. In practice this depends heavily on correct integration with your tag manager and on vendors honoring the signaled consent state. A CMP supports this control but does not guarantee that every underlying script respects it, so configuration and testing remain necessary and a CMP does not replace legal judgment.
What should we do if we discover a third-party vendor is respawning identifiers after deletion?
Common steps include documenting the observed behavior, raising it with the vendor to understand the storage mechanisms involved, and reviewing your contractual and data processing arrangements with them. Teams often reconfigure tag firing so the vendor's scripts and any backup storage are blocked until valid consent exists and are cleared on withdrawal, and in some cases suspend the tag pending resolution. Because the vendor's conduct may affect your own compliance posture, involving privacy or legal counsel to assess responsibilities is generally advisable. This entry does not prescribe a specific outcome, as the appropriate response depends on the facts, the vendor relationship, and the applicable jurisdiction.
Do the rules on zombie cookies differ between the EU, the UK, and US states?
Yes, the framing differs by jurisdiction. In most EU jurisdictions and in the UK, the primary hook is the ePrivacy rule on storing and accessing information on a device, which generally requires prior consent for non-essential storage, with the GDPR (or UK GDPR) applying to any resulting personal data. Several US state privacy laws, such as those in California, more commonly operate on an opt-out model and may not require prior consent in the same way, though they can still reach persistent tracking through their broader definitions of sale, sharing, or targeted advertising. Because obligations vary by jurisdiction and enforcement positions evolve, the applicable scope should be confirmed for each market rather than assumed to be uniform.

Common misconceptions

Zombie cookies are just ordinary cookies that happen to have a long expiry date.
Expiry duration and respawning are distinct issues. A zombie cookie is characterised by being regenerated after deletion, usually by drawing on a backup identifier held in another storage location, rather than simply by having a persistent lifetime. The two concepts should not be conflated.
Because zombie cookies use technologies other than HTTP cookies, they fall outside cookie consent rules.
In most EU jurisdictions, the ePrivacy rules on storing or accessing information on a user's device apply to similar technologies such as local storage, Flash objects, and other identifiers, not only to literal cookies. The respawning technique therefore does not escape those consent obligations, and any resulting processing of personal data may also engage the GDPR.
If a user originally consented to tracking, respawning a deleted cookie is acceptable.
Under EU frameworks, consent must generally be capable of being withdrawn as easily as it was given. Restoring an identifier after a user deletes it or withdraws consent tends to defeat that ability and would likely be difficult to reconcile with valid, unambiguous consent, though the precise assessment depends on the facts and the applicable jurisdiction.

Best practices

Audit all client-side storage mechanisms your site and third-party scripts use, including local storage, IndexedDB, cached identifiers, and any legacy Flash objects, to identify whether identifiers are being duplicated or respawned after deletion.
Ensure that when a user deletes cookies or withdraws consent, all associated identifiers across every storage location are also removed and not regenerated, so that the user's choice is honoured effectively.
Avoid deploying respawning or persistence techniques that recreate deleted identifiers, as these are generally difficult to reconcile with EU expectations that consent be withdrawable as easily as it is given.
Review third-party tags, SDKs, and vendors for hidden respawning behaviour, since zombie cookie techniques are often introduced by external scripts rather than first-party code.
Maintain clear records of the storage technologies in use and the consent obtained, and align deletion and consent-withdrawal handling with those records, recognising that a CMP supports but does not by itself guarantee compliance.
Where obligations differ across the EU, UK, and individual US state regimes, confirm the applicable requirements for your user base rather than assuming a single global standard, and seek legal judgment on contested or fact-specific points.
Promotional banner graphic asking if you are ready for PCI DSS 4.0 with a call-to-action to get the guide