Guidesad blockingad-blocker detection

How Publishers Can Detect Ad Blockers

ad-blocker blacklistsbait scriptsEasyListad reinsertionnative advertisinganti-ad-blocking scriptsbrowser extensionsIAB standardspaywalluser privacyintrusive adsprogrammatic advertisingcontent monetizationDOM inspection

The tug of war between publishers and users who resist display advertising has been ongoing for years, and there is no clean resolution in sight. Ad blockers cannot be made completely invisible to the sites they operate on, and publishers cannot make their websites completely and consistently immune to ad blockers. Both sides have partial tools — and neither has a knockout punch.

The rise of ad-blocking software has pushed publishers to develop new approaches to recover lost revenue, whether through custom ad reinsertion technology or paywalls like the one The Economist deploys.

image1

Because ad-blocking software cannot be detected directly by a website, publishers instead infer its presence by testing whether particular page elements have been rendered. That inference is the foundation of the whole detection approach: if certain elements aren't found, the publisher can display an anti-ad-block message asking the visitor to whitelist the site, or restrict access to content entirely — as Forbes does.

Forbes Forbes

How Websites Infer the Presence of an Ad Blocker

The standard approach involves implementing a "bait" script — a small piece of code that an ad blocker will recognize and suppress, precisely because it resembles an ad. Once that element is hidden, the publisher's detection logic registers its absence and responds accordingly.

Here is a classic example of a bait element:

<div class="banner_ad">...</div>

The trigger here is the class name banner_ad. That string appears in most ad-blocker blacklists, alongside hundreds of similarly named ad-related identifiers. The irony is notable: the same EasyList that AdBlock uses to suppress ads is also a useful reference for publishers designing bait. It is a double-edged sword — it tells ad blockers what to block, and it tells publishers what names will reliably trigger a block.

EasyList contains references to JavaScript files, CSS stylesheets, and images. Ad blockers compare the names of referenced scripts and files against the list; any matches are ignored. Publishers can study that same list to understand which element names will work as reliable bait. Browsing EasyList directly gives a clear sense of what ad blockers flag as suspicious.

Anti-Ad-Blocking Scripts

An effective ad-block-detection script requires only a few lines of code and is straightforward to implement. Several ready-made solutions exist for publishers who prefer not to write their own.

Detectadblock

One of the simplest detection approaches uses a bait file. A common filename that reliably triggers ad-blocking scripts is ads.js. Detectadblock.com proposes a method where a piece of JavaScript creates a hidden div inside a file called ads.js, placed in the root directory of the website:

var e=document.createElement('div');
e.id='RZfrHsidDwbG';
e.style.display='none';
document.body.appendChild(e);

Publishers then place the following JavaScript in the HTML source, just above the closing tag. Its job is to check whether the hidden div created inside ads.js exists — if it does, ads are being loaded; if it doesn't, ads are being blocked:

<script src="/ads.js" type="text/javascript"></script>
<script type="text/javascript"><br />
if(document.getElementById('RZfrHsidDwbG')){<br />
alert('Blocking Ads: No');<br />
} else {<br />
alert('Blocking Ads: Yes');<br />
}<br />
</script>

IAB Script

The Interactive Advertising Bureau (IAB) runs its own tech lab and has published an ad-block-detection script that creates a set of "bait" DIVs likely to be hidden by browser-based ad-blocking tools. The setup is straightforward, and the IAB maintains a GitHub repository with full implementation details.

BlockAdBlock (FuckAdBlock)

FuckAdBlock — also known as BlockAdBlock — is a community-developed anti-ad-blocking script that follows the same bait-and-detect pattern. The bait it uses looks like this:

baitClass: 'pub_300x250 pub_300x250m pub_728x90 text-ad textAd text_ad text_ads text-ads text-ad-links'

This triggers ad-blocking software by referencing typical class names and standard IAB-recommended ad sizes: 300×250px, 300×250px, and the 728×90px leaderboard. All of these strings appear in EasyList. The script then checks whether those elements were rendered on the page.

Alternative Approaches

Detection and messaging is only one way to respond to ad blocking. Publishers also have two other practical options: ad reinsertion and native advertising.

Ad Reinsertion

Ad reinsertion is an emerging technique that re-displays ads even after an ad blocker has attempted to suppress them. It is arguably the least user-friendly approach available to publishers. While it can be effective in the short term, it is essentially a cat-and-mouse game — ad blockers update to counter reinsertion techniques, which then require further publisher effort to circumvent. The long-term implications of ignoring a user's explicit "do not advertise to me" signal remain understudied.

Native Advertising

Native ads are inherently harder for ad blockers to detect because the ad content is implemented to resemble editorial content on the surrounding page. In-feed native ads, in particular, match the original editorial feed in both form and function, making them difficult to distinguish from organic content and therefore difficult to block.

This model is used by some of the largest platforms in the industry — Facebook, LinkedIn, Tumblr, Twitter, and Instagram all rely on native formats as a core monetization strategy. Major news publishers including Time, Forbes, The Wall Street Journal, and The New York Times have also integrated native advertising into their revenue mix.

The Publisher's Perspective on Ad Blocking

Ad blocker adoption is a material problem for publisher economics. PageFair, a recognized authority on ad-blocking trends, estimated in its 2017 report that approximately 11% of internet users were blocking ads on the web, with usage growing 30% in 2016. A striking 74% of American ad-block users say they do not even enter sites that display ad-block walls — meaning hard blocks may drive away more traffic than they recover in revenue.

Publishers typically respond to a detected ad blocker in one of two ways: restricting access to content completely (Forbes has taken this approach), or displaying a polite message explaining that advertising supports free content and asking visitors to whitelist the site — as The Guardian does.

Summary

The detection methods described here represent just a handful of the free, ready-made scripts available to publishers — a basic search will surface dozens more. Detection scripts can be simple and require only a few lines of code, making implementation accessible even outside large engineering teams.

That said, detection is only the beginning of the answer. The deeper question is why users adopt ad blockers in the first place. In most cases, the online advertising industry's own behaviour is the root cause: intrusive formats, deceptive "you've won" pop-ups, malware-laced ad networks, and systematic disregard for user privacy are the conditions that drove the ad-blocking movement to scale.

Effective long-term responses to ad blocking are less technical and more philosophical — better ad targeting, genuine respect for privacy, and ad experiences that users do not feel compelled to escape. Detection tools tell publishers who is blocking; understanding why they are blocking is what informs a durable strategy.