The Question Behind The Question

Somewhere around a third of internet users run an ad blocker. If a big slice of your audience already blocks trackers, and some blockers even hide cookie banners, it's fair to ask whether the banner is doing anything. The short answer is yes, you still need it, and the reasons are worth understanding, because they also tell you how to build the banner so it keeps working when a blocker gets in the way.

Ad blockers and consent banners look like they overlap. They don't really. One is a tool your visitor chose to protect themselves; the other is a legal obligation that sits on you no matter what tools your visitor runs.

What Ad Blockers Actually Do

An ad blocker is a browser extension (or a built-in feature, in browsers like Brave) that applies community filter lists such as EasyList and EasyPrivacy to stop ads and trackers from loading. It's effective and popular, but as a compliance mechanism it has three holes:

It's the user's choice, not your control. You can't assume anyone has one, and you can't make everyone install it. The visitors without a blocker still load whatever your site loads.
Coverage is partial. Filter lists catch known ad and tracker domains. Plenty of first-party analytics, functional cookies, and newer or self-hosted trackers sail straight through.
It keeps no record for you. An ad blocker never produces the proof of consent regulators expect. It just quietly drops requests on one device.

So even in the best case, an ad blocker protects the user who has one and leaves your obligation to everyone else completely unaddressed.

Adoption also swings hard by audience, and you can't predict it. Blocker use runs high among technical, desktop, and younger users, and much lower on mobile and among mainstream consumers. A developer-tools site and a recipe blog face completely different realities. You have no reliable way to know, visitor by visitor, who is blocking what, so building your compliance around an assumption that "most people block this anyway" is guesswork dressed up as a strategy.

The Obligation Is Yours, Not The Browser's

EU law puts the duty on the site operator, the data controller, not on the visitor's software. Two rules make this concrete:

The ePrivacy Directive requires prior consent before non-essential cookies or similar technologies are stored or read. That duty exists for every visitor who doesn't block anything, which is most of them.
The GDPR's accountability principle (Article 5(2)) means you have to be able to demonstrate a valid basis for processing. An ad blocker on someone else's laptop demonstrates nothing on your behalf.

There's a narrow point in your favor. Article 82(3) of the GDPR says a controller isn't liable for harm it had no control over, which can cover the fact that you can't stop a user from running a blocker that hides your notice. But that's about not being punished for the blocker's behavior. It is not a waiver of the requirement to run a compliant banner for the visitors whose browsers show it. Whether you need a banner at all is covered in Do I Need a Cookie Banner?

When The Blocker Hides Your Banner

Some filter lists include rules aimed at cookie notices and consent prompts (the "annoyances" and cookie-notice lists that ship with popular blockers). A visitor running those may never see your banner at all. Here's the trap: if your banner's blocking logic lives inside UI that itself gets stripped, then when the UI disappears, so does your gate, and your trackers can fire with no consent and no way for the user to refuse. That's the worst of both worlds. The banner is invisible, and the tracking still happens. The design that avoids it holds non-essential tags before any consent exists, independent of whether the banner renders.

Build It To Fail Closed

The right default is simple to state: if there's no consent signal, non-essential tags don't run. Not because the banner is showing, but as the baseline state. Then:

A normal visitor sees the banner, chooses, and their choice is applied and recorded.
A visitor whose blocker hides the banner never gets tracked either, because the default with no consent is off. They lose no privacy; you lose only the ability to measure them, which is the safe way for it to break.
Nobody is tracked on the assumption that silence means yes.

This is the difference between a banner that's a decorative overlay and one that's an actual enforcement gate. See How to Block Scripts Before Consent for the mechanics.

Where CookieBeam Fits

CookieBeam is built to fail closed. Non-essential scripts are held until a consent signal exists, so a visitor whose ad blocker strips the banner UI still isn't tracked without a basis, and a visitor who sees the banner gets a real, recorded choice. Our scanner inventories the cookies, scripts, and outbound connections your pages load in a controlled environment, so you know the full set that needs gating, rather than guessing from what happens to survive one user's blocker. The banner isn't there to fight the ad blocker. It's there to meet an obligation the ad blocker was never yours to satisfy.

Related Guides and Sources

Keep reading: Browser-Level Blocking vs Consent Management, Brave Browser and Shields, and Do I Need a Cookie Banner? Primary sources: the European Data Protection Board's Cookie Banner Taskforce report on banner requirements, and the text of GDPR Article 82 on controller liability.