Manifest V3 impact on ad blockers in 2026: what publishers lose and how to recover

Manifest V3 is the extension platform that Google introduced for Chrome and other Chromium browsers. It rewrites the rules for how extensions, including ad blockers, are allowed to operate. For publishers the single most important change is in how content blocking works.

Under the older Manifest V2, an ad blocker used the blocking form of the webRequest API. It could observe every network request the page made and run JavaScript to decide, request by request, whether to allow or cancel it. This gave blockers near-total flexibility and let them adapt instantly to whatever a site tried.

Manifest V3 removes that blocking capability for content blockers and replaces it with declarativeNetRequest. Now the extension registers a fixed set of rules in advance, Chrome compiles them, and the browser enforces them natively. The extension no longer sees individual requests or makes per-request JavaScript decisions. It is faster and uses less memory, but it is also more rigid.

Google did not flip a switch overnight. The move away from Manifest V2 ran as a phased rollout across 2024 and 2025. Chrome began disabling Manifest V2 extensions for users in stages, showing warnings, then turning extensions off, with enterprise policy escapes that themselves had end dates.

By the time the rollout completed, Manifest V2 extensions were effectively gone from mainstream Chrome. The Chrome Web Store stopped accepting new MV2 submissions well before that, so the supply of new MV2 blockers had already dried up.

For publishers the takeaway is that the ad-blocking landscape in Chrome is now an MV3 landscape. Any assumption about blocker behaviour formed before this transition is out of date. The blockers your audience runs today are either MV3-native or have been rebuilt to fit MV3 constraints.

The most visible casualty of the transition was classic uBlock Origin. Its dynamic, JavaScript-driven blocking depends on the Manifest V2 webRequest API, which is the exact capability MV3 removes. As a result, classic uBlock Origin cannot run as an MV3 extension and has been disabled for users on up-to-date Chrome.

Its author responded by building a separate extension, uBlock Origin Lite, or uBOL, designed from the start for Manifest V3. uBOL is not the same product. It relies on declarativeNetRequest, ships with predefined rule sets, and exposes Basic, Optimal and Complete permission modes that trade convenience against how much the extension is allowed to do.

Importantly, classic uBlock Origin still works fully in Firefox, which continues to support the Manifest V2 webRequest API, and in Chromium forks that kept it. So the picture is split: in Chrome the audience moved to uBOL or other MV3 blockers, while in Firefox the classic blocker carries on unchanged. A detection layer has to handle both.

declarativeNetRequest is powerful but bounded in ways that matter. Chrome caps the number of rules an extension may register, both static and dynamic, and limits how many rule sets can be enabled at once. A blocker cannot simply load every filter list ever written; it has to fit within those budgets.

It is also declarative by definition. The extension cannot inspect a request and decide in JavaScript; it can only express rules ahead of time and let Chrome match them. Anything that needs runtime logic, reacting to a page's specific behaviour, decoding an obfuscated request at the moment it fires, is much harder or impossible compared with the MV2 approach.

These limits do not make blockers ineffective. declarativeNetRequest still blocks the large, well-known ad and tracker endpoints very effectively, and it can redirect blocked requests to neutralised resources. But the rigidity is real, and it is exactly what gives a detection engine measurable, stable signals to work with.

It is tempting to read all of this as good news, uBlock Origin removed, blockers constrained, problem solved. That reading is wrong, and acting on it costs revenue.

Ad blocking under MV3 is constrained, not defeated. uBlock Origin Lite, AdGuard's MV3 build, Brave's built-in shields and other MV3 blockers all still block the bulk of display advertising. The users who chose to block ads did not stop wanting to; they simply moved to the tools that still work. Overall ad-block usage did not collapse with the MV2 deprecation.

What did change is detection. Because MV3 blockers are quieter and act mostly in the browser's network layer, the legacy single-signal detection scripts many publishers still run miss them, especially uBOL. So a publisher who assumes MV3 fixed the problem is doubly exposed: the blockers are still there, and the old detection no longer sees them. The correct response is an MV3-aware detection engine. AntiAdBlock Core retrains its heuristics nightly against EasyList, uBlock and AdGuard deltas and runs 11 voting vectors specifically so that MV3 blockers stay visible.

The detect uBlock Origin Lite 2026 guide goes deeper into how MV3's quieter footprint changes what detection signals are actually available, including how Optimal and Complete modes differ in what they block. For a 2026 update on which anti-adblock approaches have adapted to these changes, anti-adblock script 2026 is the companion reference.

The users who ran Manifest V2 blockers did not stop blocking ads, they migrated. uBlock Origin Lite is the most direct successor, and its install count on the Chrome Web Store has grown steadily since classic uBlock Origin was disabled. AdGuard released its own MV3 extension during the same period. Brave built-in shields operate at the browser level entirely outside the extension platform and were unaffected by the transition.

Firefox complicates the picture for publishers. Firefox kept the Manifest V2 webRequest API and classic uBlock Origin runs there unchanged. Firefox users skew more technical than Chrome users, so their ad-block rate is higher. A publisher whose detection layer only catches Chromium-style MV3 blockers misses every Firefox visitor running the classic extension.

The net result in 2026: Chrome ad blocking is lower than in the MV2 era, but not dramatically so. Users who wanted to block ads found tools that work. Publishers who expected the MV2 deprecation to cut their blocked-impression share by half have been disappointed. The audience still blocks; the tools just changed.

The sharpest revenue risk from MV3 is not that more users block ads, it is that legacy detection scripts stop seeing the ones already there. A script that injects a bait ad unit and checks whether it rendered will pass uBlock Origin Lite as unblocked. uBOL blocks the ad-network domain via declarativeNetRequest before the request ever reaches the rendering pipeline; the JavaScript check runs and finds nothing wrong. The publisher records no detection, serves no recovery overlay, and loses the impression silently.

This gap between what old scripts detect and what is actually blocking has a direct cost. For publishers with significant Chrome audiences, legacy single-signal detection is currently undercounting blocked visitors by a material margin. Every missed detection is an impression permanently surrendered, no paywall prompt, no whitelist ask, no recovery at all.

The action is to verify rather than assume. Open a browser with uBlock Origin Lite installed, visit your site, and watch whether your existing detection fires. If it does not, you are serving that audience at zero yield. Switching to an ensemble detection engine, one that runs multiple voting vectors instead of a single bait check, is the only reliable fix for the MV3 generation of blockers.