Rejection and deletion are two different jobs, and most consent banners only do the first — badly. Clicking Reject all typically tells the CMP to stop loading scripts from that point forward. It rarely removes cookies those scripts already wrote, and it does nothing about scripts the CMP never controlled.
The short answer
So a visitor who rejects everything can still walk away with _ga, _fbp, and a vendor session ID in their browser. Three separate things cause that, and they need three separate fixes: cookies written before the click (the banner was too slow or not blocking at all), cookies written after the click by scripts outside the CMP's control, and cookies simply never cleaned up on withdrawal.
Worth separating from the legal noise: the cookie sitting in the jar is not itself the thing pre-consent claims are built on — those are about transmission. But a jar full of tracking cookies after a rejection is the clearest possible evidence that the banner is decorative, and it is the first thing anyone auditing you will look at.
Open Application → Cookies after clicking Reject all and the list is not empty. Some entries are yours and fine — a session cookie, the CMP's own consent record, a CSRF token. Others are unmistakably tracking: _ga and _ga_<id>, _fbp, _gcl_au, _hjSessionUser_…, _clck / _clsk, li_sugr, __kla_id.
Reload the page after rejecting and watch: if any of those reappear with a fresh timestamp, something is still executing. If they persist but do not refresh, they are leftovers from before the click.
This test distinguishes the three causes, which matters because the fixes are different.
.yourdomain.com follow the visitor across every subdomain. A cookie you "removed" on www can still be live at the apex.What a healthy result looks like: After a rejection and a reload, the only cookies left should be ones you can name and justify: session, security, and the CMP's own consent record. Everything else is a finding.
If scripts run at page load, the cookies exist before the visitor has any opportunity to reject. Rejection then has nothing to prevent — the damage is already in the jar. This is the same root cause as trackers firing before consent, seen from the storage side.
Most consent platforms treat their job as preventing scripts from loading. Deleting cookies previously written by those scripts is a separate feature that is often optional, often off, and often only covers cookies the platform recognizes.
A hardcoded snippet in the theme, a plugin-injected tracker, or a tag fired by a container the CMP does not govern will keep setting cookies after a rejection, because nothing ever told it a rejection happened.
Even a well-behaved script needs to be told. If the CMP does not call gtag('consent','update',…), fbq('consent','revoke'), or the equivalent vendor call, the vendor's SDK carries on with whatever state it started in.
California's Invasion of Privacy Act (CIPA), Penal Code § 631, prohibits intercepting a communication without the consent of all parties. Since 2022, plaintiff firms have applied that decades-old wiretapping statute to websites — arguing that trackers continuing to write identifiers to a visitor's browser after the visitor declined before the visitor consents is an intercepted communication. Statutory damages under § 637.2 run up to $5,000 per violation, and plaintiffs argue each affected visitor session is a separate count, which is why even small sites receive demand letters. Similar all-party-consent statutes in Pennsylvania (WESCA), Florida (FSCA), and Massachusetts have produced parallel filings.
To be precise about what a network log can tell you: a tracker firing before consent is a technical finding — it establishes when a script transmitted data, not whether any law was broken. But timing is exactly what these claims are built on, which is why fixing the timing is the practical response.
Terminology bridge
Consent platforms call the "stop scripts before a choice is made" behavior prior blocking (sometimes auto-blocking), and the "clean up afterwards" behavior cookie deletion on withdrawal or consent revocation handling. The list of every cookie your site sets, with purpose and duration, is a cookie inventory or cookie audit — most CMPs generate one, and it is worth reading because it usually contains rows nobody on your team can explain. A banner where accepting is easier than rejecting is what regulators call a dark pattern.
A cookie audit shows storage; a network log shows transmission. They answer different questions, and the claims driving this whole area are about transmission. A scan can tell you that a tracking cookie exists after a rejection and that requests still go out — it cannot tell you whether any particular configuration satisfies any particular law. That is a question for a qualified attorney, and this page is general information, not legal advice.
RegSentry loads your site in a real browser, records when each third-party tracker first contacts its server, and flags everything that fires before consent — with the fix for each one. Continuous monitoring re-runs it and emails you when something new appears.
Free real-browser scan
See every pre-consent tracker on your site — free, 30 seconds, no signup.
Real browser scan, no signup to run it. You see a summary of the findings; the full report with every tracker unlocks with your email.