Ad blocking on Firefox: a publisher's detection guide

Firefox is a small slice of overall browser share, but it is a slice that matters out of proportion to its size for ad-supported sites. Its audience skews privacy-conscious and technical, and Firefox has historically carried one of the highest ad-blocker usage shares among the major browsers. For a publisher, that means the blocked-session rate on your Firefox traffic is often noticeably higher than on Chrome, even though Firefox is fewer of your total visits.

The deeper reason Firefox deserves its own treatment is technical, not demographic. Mozilla made an explicit, public commitment to keep supporting the Manifest V2 blocking form of the webRequest API, the exact capability that Chrome removed in its move to Manifest V3. Firefox did not follow Chrome down the declarativeNetRequest-only path, so the extension platform underneath an ad blocker on Firefox is the older, more powerful one.

The practical consequence is that the dominant blocker on Firefox is the classic, dynamic, JavaScript-level kind. A publisher who has tuned their whole anti-adblock strategy around the post-MV3 Chrome world will have a blind spot on Firefox, because the blockers there work in the older paradigm that those strategies were quietly leaving behind. Treating Firefox as just another Chromium tab is the mistake.

This is the single most important fact for publishers. Because Firefox keeps the Manifest V2 blocking webRequest API, classic uBlock Origin, the original, dynamic blocker, not uBlock Origin Lite, runs there with its full feature set. It can observe every network request the page makes, decide in JavaScript whether to cancel each one, inject scriptlets, rewrite responses and apply rich cosmetic filtering, exactly as it always could.

Contrast this with Chrome. There, classic uBlock Origin depends on a capability that Manifest V3 removed, so it has been disabled on up-to-date Chrome and its author shipped a separate, MV3-native extension, uBlock Origin Lite, built around the more limited declarativeNetRequest API. The two are different products with different runtime behaviour. On Firefox you are facing the powerful original; on Chrome you are increasingly facing the constrained Lite.

For detection this is the defining difference. The classic blocker is noisier in the page: it leaves observable side effects when it cancels a request in JavaScript, hides a bait element with a cosmetic filter, or injects a scriptlet. Those signals, DOM bait being hidden, network bait failing, cosmetic-filtering artefacts, are exactly the ones the oldest anti-adblock scripts were built to read. The classic paradigm is, paradoxically, the more detectable one, provided your detector is still tuned to look for it.

Firefox ships Enhanced Tracking Protection, or ETP, turned on by default. In its Standard setting it blocks known trackers, cryptominers and fingerprinters using curated lists; the Strict setting is more aggressive and blocks more. ETP is a meaningful part of why Firefox feels privacy-first out of the box, and it operates without the user installing anything.

It is important for publishers to understand what ETP does and does not do. ETP targets trackers, not all advertising. There is real overlap, many tracking endpoints are also ad endpoints, so some ad-related requests are blocked as a side effect, but ETP is not designed to strip every ad from a page the way a dedicated ad blocker is. Describing Firefox as shipping with a built-in ad blocker overstates it.

The takeaway is that a Firefox visitor can sit at several different points on a spectrum. Some run only the default ETP, which blocks trackers but leaves much display advertising intact. Others add a classic ad blocker like uBlock Origin on top, which is the case that costs you most impressions. A detection layer should not assume Firefox equals fully blocked, nor assume the default settings are harmless; it has to actually measure each session.

Ad blocking on Firefox is not a desktop-only concern. Firefox for Android supports browser extensions, including uBlock Origin, which is unusual among mainstream mobile browsers, most mobile Chrome users cannot install an extension at all. That makes Firefox a genuine channel for mobile ad blocking, not a theoretical one.

For a publisher, this means your mobile Firefox traffic can carry a blocked-session rate much closer to your desktop figure than you would expect from other mobile browsers. If you have historically assumed that mobile traffic is largely safe from ad blocking because most mobile browsers cannot run extensions, that assumption breaks specifically on Firefox for Android.

The implication for measurement is simple but easy to miss: do not segment ad blocking as a desktop-only metric. A detection script needs to run and report on mobile Firefox the same way it does on desktop, and your analytics should be able to show you the Firefox mobile slice separately, because it can behave very differently from mobile Chrome or Safari.

The detection implication of everything above is concrete. On Firefox the dominant blocker is the classic, MV2, JavaScript-level kind, and that kind leaves observable signals: DOM bait that gets hidden by a cosmetic filter, network bait requests that get cancelled, and timing artefacts from runtime blocking. A detector that knows to look for the dynamic paradigm can read Firefox well.

The failure mode is a detector that has been narrowed to the post-MV3 Chrome world. If your script assumes blocking happens silently in the browser's network layer through declarativeNetRequest, and only probes for that, it will mis-handle Firefox, sometimes missing classic uBlock Origin entirely, sometimes misreading its richer cosmetic behaviour. An MV3-only detector and a Firefox audience are a bad match, and the result is false negatives: blockers present, revenue lost, script reporting nothing.

The robust answer is an ensemble that covers both paradigms rather than betting on one. AntiAdBlock Core runs a multi-signal engine that spans the classic dynamic, JavaScript-level blocking common on Firefox and the declarativeNetRequest model common on Chrome, with heuristics retrained nightly against EasyList, uBlock and AdGuard filter deltas. Across the current landscape it reports around 99.7% detection precision, and because it votes across many independent vectors no single filter rule on one browser switches the whole thing off.

Once detection is reliable on Firefox, recovery is the same disciplined work it is anywhere: measure your real blocked-session rate, show a polite, on-brand recovery message rather than a hostile wall, and read the recovery rate before tuning tone and timing. The point of getting Firefox right is that it is often where your blocked-session rate is highest, so it is frequently where careful detection recovers the most.

Firefox's continued Manifest V2 support makes it the strongest platform for classic detection signals, but the anti-adblock script guide explains why you still need MV3-aware vectors for the growing share of your audience on Chrome. For JavaScript detection examples that work across both paradigms, detect adblock with JavaScript 2026 covers the technical implementation.