You install an extension, the cookie banner disappears, and the page looks clean. That is not the same thing as having rejected anything.
A banner is a UI element. Consent is a state the site records — usually in a cookie or localStorage — and later reads back before deciding which scripts to load. If the banner was only hidden with display: none, the site may still be running with no recorded choice at all, which for many implementations means the non-essential scripts load anyway. The popup is gone; the tracking isn't.
This post is about telling the two apart, using the browser you already have. No extension required to run the checks.
Three things an "auto-reject" tool can actually do
| Approach | What happens | What the site sees |
|---|---|---|
| Hide the banner | CSS removes the popup from view | No consent state written; scripts follow their default path |
| Click the real reject control | The extension finds and clicks the site's own "Reject all" button | The consent platform records an explicit opt-out |
| Call the consent platform's API | The extension invokes the platform's own method to set the choice | An explicit opt-out, without depending on the button's markup |
Only the last two produce a choice the site can act on. The first one produces a screenshot that looks identical to the other two.
There's a fourth signal that's independent of the banner entirely: Global Privacy Control (Sec-GPC: 1). It's a browser-level opt-out signal recognized under CCPA/CPRA regulations in California and several other US states. A tool can send it even on sites with no visible banner. You can read it in the console:
navigator.globalPrivacyControl A five-minute audit of your own blocker
Pick a site you've never visited in this browser profile — ideally one known to show a consent dialog — and keep DevTools open.
1. Look at the DOM, not just the screen. Right after load, use the Elements panel and search for the word reject. If the banner node is still in the DOM with display: none or visibility: hidden, the choice was never submitted — only the UI was suppressed.
2. Inspect consent state. In Application → Storage, look at cookies and localStorage keys containing consent, cookie, cmp, or privacy. This snippet prints the useful ones:
const keys = Object.keys(localStorage) .filter(k => /consent|cookie|privacy|cmp/i.test(k)); console.table(keys.map(k => ({ key: k, value: String(localStorage.getItem(k)).slice(0, 160) }))); console.log('cookies:', document.cookie); console.log('GPC:', navigator.globalPrivacyControl); What you want to see is a recorded negative state — a value that says the optional categories were declined. What you don't want is no entry at all, or a state that still says "pending".
3. Watch the network. With the Network tab recording, do a hard reload. Filter for third-party analytics/ad domains. A real opt-out should reduce or remove those requests; a hidden banner usually won't change them.
4. Reload and stay clean. Close and reopen the tab. If the banner comes back on every visit, the tool is hiding it per page rather than registering a choice.
5. Check a regional site. Consent platforms vary by country and by site, and many local sites use their own markup. A tool that works on one large vendor's widget but silently gives up elsewhere will pass steps 1–4 on your usual sites and fail here.
Why "hidden" is the common failure mode
Hiding is cheap and reliable. Clicking a real button means dealing with labels in many languages, buttons nested in shadow DOM, iframes, and widgets that rewrite themselves on scroll. Calling a platform API means knowing which platform is present. So the easy implementation is the one that just makes the popup go away — and it's also the one that gives the user no privacy outcome.
That's also why a tool that does submit a real choice is worth testing rather than trusting. Try a site in a language you don't normally browse in. Try one where the reject control is a text link rather than a button. Then run the five checks again.
What I use
I ended up building a small extension for this, CookieGuard. It presses the site's actual reject control (or uses the consent platform's own method where one is available), verifies the result, and sends the GPC signal. I'm the developer, so treat that recommendation accordingly — the five checks above work on any tool, including the one you already have.
The one-line version
A missing banner is a UI outcome; a recorded rejection is a privacy outcome. Check localStorage/cookies for a real negative state, look at third-party requests after a hard reload, and confirm navigator.globalPrivacyControl — then you'll know which one you got.
