How Websites Detect Your Ad Blocker (and When They're Wrong)

You clicked through to an article and got a wall instead: “Ad blocker detected. Please disable it to continue.” Maybe the accusation was fair. Maybe you don’t run an ad blocker at all and the site still insists you do. Either way, the site never saw your extension list, and it caught you anyway.

There is no API that hands a web page your extension list. So anti-adblock scripts don’t look for the blocker. They plant things a blocker would remove, then check what survived. The widget on this page runs six of those traps against your browser right now; the rest of this article explains what each one is doing.

The economics are simple: ads pay for the page, blocked ads pay nothing, and a wall that converts a slice of blocking visitors back into impressions is worth annoying the rest. That is the entire reason the scripts below exist.

The bait element: caught by what’s missing

Nearly every ad blocker ships the same core rules: EasyList, a community-maintained catalog of what advertising looks like on a page. Alongside tens of thousands of URL patterns, it carries cosmetic rules: hide any element with class names like ad-unit or adsbox.

That catalog is public, so anti-adblock scripts read it too. The oldest trick in detection is to create an invisible one-pixel div wearing exactly those class names and read its offsetHeight. An unblocked browser reports the pixel. A blocked one reports zero, because a cosmetic filter set the div to display: none. The page never saw your extension. It saw a div stop existing.

This is the “CSS bait” check in the widget above, and the engine inside the old BlockAdBlock and FuckAdBlock libraries that half the detect-adblock tutorials on the internet still repackage. That indirection is the same move anti-bot systems make when they hunt browser automation: nobody can see Puppeteer either, only what Puppeteer changes.

The requests that never come back

The second family of traps works on the network. Blockers don’t just hide elements, they refuse to fetch from known ad servers, so the page sends decoys: a script from pagead2.googlesyndication.com, an image from tpc.googlesyndication.com, a fetch() to ads.pubmatic.com. Real ad infrastructure, requested on purpose. If the error handler fires instead of the load event, something on your machine killed the request. Chrome’s console even names the culprit: net::ERR_BLOCKED_BY_CLIENT.

Four of the widget’s six checks are this shape, one per request type, because filter rules treat scripts, images, CSS-loaded images and fetches differently, and a blocker can be caught on one while passing another.

Many publishers skip the decoys entirely. Google’s own ad script, adsbygoogle.js, defines a JavaScript object when it loads, and the page simply checks whether that object exists. When the real ad script is its own bait, blocking it and announcing yourself become the same event.

How YouTube detects your ad blocker (and why it’s different)

YouTube doesn’t bother with bait divs. Its player knows which ads the server attached to the stream, expects its own playback events to fire, and carries detection logic inside the player JavaScript, obfuscated and reshuffled often enough that filter-list authors have to keep patching around it. Google has also experimented with server-side ad insertion, stitching ads directly into the video stream where no filter list can reach them. That is a different weight class from a copy-pasted bait script, and it is backed by policy: Google’s position is that ad blockers violate YouTube’s Terms of Service. The arms race there is fast and specific, which is exactly why “how does YouTube detect adblock” has no stable answer. The bait mechanics on this page do have one, and they are what the other ninety-nine percent of “please disable your ad blocker” walls run on.

Accused with no ad blocker installed

Type “adblock detected” into Google and one of the top suggestions is “adblock detected but no adblock”. The traps explain the confusion: they fire on blocking, wherever it lives.

• DNS filtering. A Pi-hole, NextDNS, or a router with ad filtering kills the decoy request before it leaves your network. To the bait, that looks exactly like uBlock Origin.
• Browsers that block by default. Brave’s Shields drop ad requests out of the box, and Firefox’s strict tracking protection blocks known ad and tracking domains. No extension required.
• Other extensions. Cookie-banner removers and privacy tools hide elements and block requests for their own reasons, and spring the same traps.
• Security software. Antivirus suites with “web protection” filter ad domains for the whole machine.

The detector cannot tell which layer ate its bait, and the nag screen doesn’t care. If this is your situation, the widget above does the diagnosis: it names which of the six checks fired. An element check points at something hiding page content; request checks point at something on the network path.

How to stop websites from detecting your ad blocker

You have three honest options and one blunt pair.

• Whitelist (allow-list) the site in your blocker. The outcome the wall exists to produce, and the mechanism Adblock Plus institutionalized as its default-on Acceptable Ads program.
• Keep your filter lists current. The same ecosystem that blocks ads also blocks anti-adblock: EasyList maintains a dedicated Adblock Warning Removal List, and uBlock Origin ships Annoyances lists that strip many walls before you ever see them.
• Pay for the sites you actually read. Ends the standoff outright.
• Reader mode, or JavaScript off. The blunt pair: both kill the detector along with everything else that makes the page work.

Blocking ads is legal, and a site refusing to serve you until you stop is legal too. Germany’s top court said as much in 2018, when publishers sued the makers of Adblock Plus and lost. With the law settled on both sides, all that’s left is the arms race.

Your blocker joins your fingerprint

For our comparison of five popular ad blockers we ran these same six checks against each one, and the spread was wide: Adblock Plus tripped five of six, uBlock Origin two, Ghostery just one.

Two things follow. First, blockers are not equally loud, and “detectable” is a property you can shop for. Second, the pattern itself is information. Which traps fire depends on which blocker and which filter lists you run, so the result rides along with your font fingerprint and canvas hash into the profile a tracker builds. An ad blocker does not make you invisible. It makes you someone who blocks ads in one specific, measurable way.

What to actually do

1. See what fires. Run the widget on this page, then the full browser scan for everything adjacent: fingerprint hashes, WebRTC, the works. Knowing which checks catch you is the difference between guessing and fixing.
2. Wrongly accused? Find the layer. Disable your extensions and reload. Still detected means the blocking sits deeper: DNS filtering, browser defaults, or antivirus web protection. Allow-listing a site inside an extension you don’t have will never fix a block your router is doing.
3. Running multiple accounts? Mind the pattern. A blocking pattern is one more trait that has to stay consistent per identity, session after session. Incogniton keeps each profile a fully separate browser with its own extensions and settings, so profile A’s blocking habits never bleed into profile B’s fingerprint.

The next time a site swears you are running an ad blocker, you’ll know what it actually caught: a div that lost its height, or a decoy that never came back. The widget above tells you which one gave you away.