Why does a tracking cookie come back after rejection?
On this page
Usually because the script that set it is still running. Deleting a cookie does not stop the code that wrote it: if that code has not been told consent is denied, it writes the cookie again on its next hit. The other causes are a delete aimed at the wrong domain or path, and a cookie your server sets.
Why does a deleted cookie reappear after someone rejects?
A cookie is a file the browser keeps. The tag that set it is code that runs in the page, and it keeps running after the banner closes. Delete the file and the code is still there, ready to write it back the next time it sends something.
We reproduced this with Google’s real gtag.js on a test domain in November 2026. With analytics still granted, we deleted _ga and _ga_<id> correctly. Both were gone. The next event the tag sent wrote the session cookie, _ga_<id>, straight back. On a client site we worked on the same month, an analytics cookie came back when the page was hidden rather than on an event. Teams often read this as the consent tool failing. It is the order of operations failing.
The fix is to tell the tag first. In the same test, sending gtag('consent', 'update', { analytics_storage: 'denied' }) and then deleting the cookies kept them gone through another event and a simulated hidden page. A tag that knows consent is denied stops writing; one that does not will undo your delete.
Why does deleting the cookie seem to do nothing?
Because the delete has to match the cookie it targets. A browser only removes a cookie when the name, domain and path of the delete match the ones it was set with, as MDN’s reference for the Set-Cookie header describes. Google tags set theirs on the highest level of domain possible, so on shop.example.com the _ga cookie lives on .example.com.
In our test, a delete written as document.cookie = '_ga=; Max-Age=0; path=/', with no domain, removed nothing at all. The script ran without an error and the cookie stayed. Add domain=.example.com and it goes. The same applies to path: a cookie set on a path other than / is not reached by a delete on /.
Same cookie, four attempts, one that holds.
What about cookies the server sets?
A cookie marked HttpOnly cannot be read or deleted by any script on the page. Server side tagging setups often use one, for example the FPID cookie a server container can issue. Only the server can expire it, so the server has to know about the rejection and act on the next request. If you run a server container, check that its client reads the consent state and stops issuing the cookie when it is denied. Passing the consent signal to a server container covers that half.
Is the cookie really back, or did it never leave?
Check before you fix. Some cookies are meant to stay: your consent record, and strictly necessary ones such as a session or basket cookie. Cookies on another company’s domain cannot be removed by your site at all. Then open the browser’s storage panel and look at the domain column. A cookie on the parent domain can belong to another site you run on the same domain, and that site’s own banner is the one that decides. A cookie with a new value was written again. One with the old value was never deleted. And if it appeared before the visitor chose anything, the tag ran before the denied default was set, which is a load order problem rather than a deletion one. Our post on checking whether a tag really sets cookies walks through reading those panels.
How do you stop a cookie coming back after rejection?
Send the denied signal first
Tell every tool in the format it listens for before you touch storage: a consent update for Google tags, the equivalent call for each other vendor. A tag that knows consent is denied stops writing.
Delete on every domain level
Delete each cookie on the current host and on every parent domain up to the registrable one, with
path=/. A delete without the domain silently misses cookies set on the parent.Hold back tags that have not run
Make sure nothing waiting to load can start after the rejection and write the cookie fresh. That is the job of the tag gate, not the delete.
Expire server cookies on the server
For any
HttpOnlycookie, have the server read the consent state and expire the cookie on the next request. No page script can do it.Test across a hidden page and a reload
Accept, then reject, then send an event, switch tabs, and reload. Read the cookie panel after each one. A rejection that holds only until the next hit is not holding.
For the full order a withdrawal should follow, including the identity reset most libraries need, see what happens when someone withdraws cookie consent.
How Velo handles it
When a visitor rejects a category they had allowed, Velo sends the denied signal to each vendor it is set up to tell, then deletes the known first party cookies and storage keys for that category on the current host and every parent domain up to the registrable one, with path=/. It cannot reach HttpOnly cookies or cookies on another path, and it leaves its own consent record alone, because that record is what proves the rejection happened.
Common questions
What people ask about this topic.
Why does a tracking cookie come back after a visitor rejects or withdraws consent?
Usually the script that set it is still running and has not been told consent is denied, so it writes the cookie again on its next hit. Send the denied signal first, then delete the cookie.
Why does my delete not remove the _ga cookie?
Google tags set the cookie on the highest level of domain possible, and a browser only deletes a cookie when the domain and path match. Delete it with the parent domain and path=/ as well as on the current host.
Can a consent banner delete every cookie?
No. A page script cannot delete HttpOnly cookies, cookies on another path, or cookies belonging to another site. Server cookies have to be expired by the server that set them.
Does a reload stop the cookie coming back?
A reload ends every script from the previous state, so it helps. It only holds if the stored rejection is applied before any tag runs on the new page.
