Dev.to WebDev 🛠 Dev 👁 0 📖 4 min read

Your cookie banner blocker may just be hiding the banner. Here's how to check

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 cook

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.

📰 Read the original article on Dev.to WebDev

Originally published by Dev.to WebDev. Aggregated on AIWithGhost for educational purposes — full credit and traffic to the original publisher.