Anti-adblock code: common patterns, pitfalls and what actually holds up

The most widely copied anti-adblock code is the bait div: a DOM element with an ad-like class name, checked after a short delay to see whether the blocker hid or removed it.

We deliberately do not publish a runnable snippet here. The method itself is no secret: create an invisible element whose class name matches an ad-related entry on a public filter list such as EasyList, wait a moment, then check whether a blocker hid it. The problem is exactly that it is public and static. A fixed, well-known class name is the first thing a filter-list maintainer copies into a rule, and from then on the check quietly returns 'no blocker' for every visitor who carries that list.

This works against blockers that apply cosmetic filtering, hiding elements by class selector, because those blockers will hide the bait and the check fires. For a basic blog wanting a rough count, it is a reasonable first probe. But it fails silently in more cases than it catches, which is the dangerous kind of failure.

A second common pattern is the fetch probe: loading a URL that looks like an ad network resource and treating a network failure as evidence of a blocker.

Again, we do not ship a runnable probe here. The idea is to request a path that looks ad-related and treat a failure as a blocker, which catches network-level blockers that a cosmetic check misses. In practice it is fragile: the probe path is another fixed, listable signature, a plain 404 or a corporate firewall looks identical to a real block and produces false positives, and under Manifest V3 the request is stopped in the browser engine before your code runs, so the signal is easy to misread.

Fetch probes reach blockers that operate at the network layer. But the false-positive rate is meaningful: a slow connection, a CDN glitch or a browser security policy can all trigger the catch branch without any ad blocker present. And if the specific URL you probe falls off the filter list, the probe returns false negatives forever while appearing to still run.

Every pattern described above shares the same structural weakness: it is static. The class name adsbox, the URL pagead2.googlesyndication.com, the variable name detectAdBlock, anything fixed and public is something a filter-list maintainer can copy into a rule. EasyList, uBlock Origin and AdGuard supplementary lists all contain rules targeting known anti-adblock code patterns.

Once your bait class or probe URL is on a filter list, the evasion is permanent until you change it. The blocker either hides the bait in a way the code does not recognise as hiding, ignores the element entirely, or blocks the probe URL before the fetch resolves. The code still runs, still reports a result, but the result is always negative, regardless of whether a blocker is present.

The fix is to never use a fixed, recognisable value as a detection signal. Bait class names should not be fixed or predictable. Probe URLs should not point at a public ad-network endpoint, and should not depend on a request to a flagged external domain.

Chrome's Manifest V3 replaced dynamic webRequest blocking with declarativeNetRequest, where the browser enforces a fixed rule set at the network layer. uBlock Origin Lite is built entirely on this model. From the page's JavaScript perspective, blocking happens below any observable event: no onerror fires, no rejected promise, no DOM mutation, just a request that resolves instantaneously with no data.

A bait div check will not detect a declarativeNetRequest blocker if the blocker uses network rules rather than cosmetic filters for the bait path you chose. A fetch probe will not resolve to catch() because the block does not cause a JavaScript-visible network error, it returns a response that looks like a normal one. Both patterns fail on this class of blocker, which is now the fastest-growing segment.

What does survive MV3 is behaviour. A request blocked natively by declarativeNetRequest behaves differently from a genuine network error or a real asset load. Reading that difference across multiple probe requests, combined with MV3 heuristics, gives a signal unique to MV3 blockers that survives their lack of JavaScript-visible side effects.

The what an anti-adblock script is guide explains why detection that survives MV3 in practice runs as an ensemble that does not depend on any single blocker behaviour. If you are weighing whether to build or buy, the anti-adblock script 2026 guide lays out that decision clearly.

Detection that holds up needs properties no single snippet can provide, and building them yourself is a standing engineering commitment rather than a one-off paste. It has to combine several independent checks so that no single filter rule takes the whole thing down at once, and it has to keep working as the lists change.

It also has to present no fixed, public signature for a filter list to capture, because anything static and recognisable gets listed and then quietly stops working. Keeping that surface unpredictable is not something a copy-paste snippet does.

Third, maintenance. Anti-adblock code is not write-once software. Filter lists update daily, new blocker versions ship, and new scriptlet countermeasures appear regularly. A snippet you paste today will detect a shrinking fraction of blockers next month without a single visible error. That ongoing upkeep is the real cost, which is why most publishers are better off pointing a single line of code at a maintained service like AntiAdBlock Core than owning the arms race themselves. If you are weighing providers, the adblock recovery software page sets out the two kinds, managed rev-share networks and detection scripts, and what to expect from each.

Before you settle on any approach, it is worth knowing how ad blockers bypass detection scripts, because that is what decides how long your code keeps working.