Manifest V3 and uBlock Origin: What Chrome Changed

Manifest V3 is the extension platform that Chrome has required since July 2025, and it is the reason ad blockers like the original uBlock Origin stopped working the way they used to. Chrome's old Manifest V2 extensions, including the blocking network-request APIs that let an extension inspect and cancel any request in real time, are gone from the browser entirely. In their place, Chrome gives extensions a more limited, rule-based system called declarativeNetRequest, which is faster and more private but caps how many filtering rules an extension can apply and how dynamically it can respond to a page. That is why Chrome users searching for "uBlock Origin removal" or "uBlock Origin Lite" are being pushed toward a thinner version of their old ad blocker, or toward switching browsers entirely for the strongest filtering.

What Manifest V3 Actually Is

A "manifest" is the configuration file every browser extension ships with, declaring its permissions, background scripts, and what it is allowed to touch. Manifest V2 and Manifest V3 are two generations of that specification for Chromium-based browsers. Google designed Manifest V3 around three goals it states directly in its own developer documentation and blog posts: better security, better performance, and better user privacy. In practice, that meant retiring some of the most powerful — and most abusable — capabilities Manifest V2 extensions had, including a background page that could run indefinitely and a version of the webRequest API that let an extension read and alter every network request a tab made before it reached the page.

Those capabilities were genuinely useful for ad and tracker blockers, which is exactly why removing them became the most contentious part of the Manifest V3 rollout. They were also, according to Google, a meaningful source of the browser's worst extension-related security incidents, since a compromised or malicious extension with that level of access could intercept banking credentials, inject code, or silently rewrite pages. Manifest V3 does not ban content blocking. It instead moves the blocking decision out of the extension's own JavaScript and into the browser itself, via a new, declarative rules API.

The Manifest V2 Deprecation Timeline, in Plain English

Google has published the exact rollout dates on its Chrome for Developers site, and the schedule stretched across several years rather than landing all at once:

• January 2022: The Chrome Web Store stopped accepting new Manifest V2 extensions set to "Public" or "Unlisted" visibility.
• June 2022: The Store stopped accepting new Manifest V2 extensions entirely, including "Private" ones.
• June 3, 2024: Chrome's Beta, Dev, and Canary channels began showing a warning banner on the chrome://extensions page telling users their Manifest V2 extensions would soon lose support.
• October 9, 2024: Chrome began disabling installed Manifest V2 extensions in the stable channel, rolling the change out gradually and pointing affected users toward Manifest V3 alternatives in the Web Store. Enterprises managing Chrome with the ExtensionManifestV2Availability policy were exempted, initially until June 2025.
• March 31, 2025: Manifest V2 extensions were disabled by default across all channels, though users could still manually turn them back on for a while longer.
• July 24, 2025 (Chrome 138): Manifest V2 extensions were disabled for every user on every channel, with no way to re-enable them. Only the enterprise policy kept a shrinking set of business-managed Chrome installs running Manifest V2 a little longer, before that exemption was removed in Chrome 139.
• August 31, 2026: All remaining Manifest V2 listings were pulled from the Chrome Web Store. Extensions that users had already installed on Chrome 138 or earlier kept running, but they can no longer be updated or reinstalled.

If a browser update this year quietly turned off an ad blocker, a privacy tool, or an old productivity extension, this timeline is almost certainly why. The same rollout schedule has run alongside Chrome's ordinary version cadence, which is worth keeping in context if you are also tracking general Chrome release and version numbering changes separately from the extension-platform shift described here.

Why Ad Blockers Specifically Got Hit the Hardest

Most extension categories survived the Manifest V3 transition with only modest rewrites. Content blockers were the exception, for a structural reason: the most capable ad and tracker blockers under Manifest V2 worked by registering a "blocking" webRequest listener, a piece of the extension's own JavaScript that Chrome would pause to consult, synchronously, for every single network request a page made. That listener could inspect a request's full URL, headers, and context, decide in real time whether to block, redirect, or modify it, and update its own filtering logic on the fly based on remote lists, user-created rules, or even the contents of the page.

Manifest V3 does not allow that kind of live, in-extension decision-making for network requests. Instead, filtering rules have to be handed to the browser ahead of time, in a format the browser itself evaluates. That is a deliberate trade: Google's stated reasoning, discussed below, is that it closes off a class of privacy and security risk. The trade-off is that an extension can no longer react instantly to brand-new tracking techniques, run filter logic that depends on page content, or exceed the rule-count ceilings Chrome sets. Ad and tracker blockers lean on exactly those capabilities more than almost any other type of extension, which is why they absorbed the biggest practical hit.

declarativeNetRequest: The API That Replaced Blocking webRequest

The replacement system is called declarativeNetRequest, and Chrome's own API reference explains both what it does and why it is built the way it is. Rather than letting an extension inspect live traffic, an extension registers sets of declarative rules — match this pattern, then block, redirect, upgrade to HTTPS, or modify headers — and the browser's own network stack applies them. Google's documentation states this approach lets the browser change requests "without intercepting them and viewing their content, thus providing more privacy," since the extension's own code never sees the traffic it is filtering.

Rules are organized into three kinds of rulesets, each with its own ceiling:

• Static rulesets are packaged with the extension as JSON files. An extension can ship up to 100 of them, with 50 enabled simultaneously, and each enabled ruleset is guaranteed at least 30,000 rules (more may be available depending on what else is installed).
• Dynamic rules are added and removed by the extension's own code at runtime and persist across browser restarts and updates. As of Chrome 121, extensions can hold up to 30,000 total dynamic rules, a sharp increase from the original 5,000-rule cap that defined the earliest, more restrictive version of Manifest V3.
• Session rules work like dynamic rules but are cleared when the browser closes or the extension updates, capped at 5,000.

Chrome's documentation is explicit that these ceilings exist because of performance cost, not just as an arbitrary restriction: "there is a performance overhead to loading and evaluating rules in the browser, so some limits apply." Those limits have already moved upward more than once since Manifest V3 launched, following the kind of developer pushback described in Google's own posts on the rollout, but the ceiling itself has not disappeared — it is a structural feature of how declarativeNetRequest is designed, not a temporary bug.

Manifest V2 vs. Manifest V3: What Changed for Content Blockers

uBlock Origin vs. uBlock Origin Lite: What Actually Changed

The clearest real-world example of this shift is uBlock Origin itself. The original uBlock Origin, built on Manifest V2's blocking webRequest model, cannot run on current versions of Chrome at all — it depends on an API Chrome no longer exposes. Its developer's own project documentation, on uBlock Origin's GitHub wiki, is candid that the extension "works best on Firefox" specifically because Firefox still supports capabilities Chromium-based browsers do not, including CNAME uncloaking (unmasking disguised third-party trackers) and HTML response filtering, which the project notes is "currently only available in Firefox."

For Chrome, the same developer maintains a separate, purpose-built project: uBlock Origin Lite (uBOL), described in its own repository as "an efficient content blocker based on the MV3 API." Rather than trying to force the old filtering engine into Manifest V3's constraints, uBOL was rebuilt around declarativeNetRequest from the start. According to the project's own documentation, uBOL "operates entirely declaratively, meaning no permanent process is required for filtering," and the browser itself performs the CSS and JavaScript injection used for cosmetic filtering — which the project says keeps the extension from consuming CPU or memory while it blocks. Its default configuration bundles uBlock Origin's own default filter set along with EasyList, EasyPrivacy, and Peter Lowe's list, with more lists available as optional, user-enabled rulesets.

What that trade buys you is a lighter, more sandboxed extension that cannot be weaponized the way a Manifest V2 extension with full request access could, and that runs without an always-on background process. What it costs, compared to the old uBlock Origin, is the ability to apply certain complex, dynamically-generated filters and some of the live customization power that advanced users relied on, bounded by the same declarativeNetRequest rule ceilings every other Manifest V3 blocker now shares.

Is Chrome Ad Blocking Actually Weaker Now? What's Settled vs. Contested

It is fair to say, and verifiable from Chrome's own documentation, that Manifest V3 removed specific technical capabilities — the blocking webRequest API and unlimited, code-driven rule logic — that the most advanced Manifest V2 content blockers used. It is also fair to say Google has responded to filtering-specific criticism by repeatedly raising declarativeNetRequest's rule ceilings, including the jump from 5,000 to 30,000 dynamic rules, and by changing the limits structure after what its own blog post describes as feedback that developers "initially felt Manifest V3 could impact their ability to provide users with the features they've come to expect."

What remains genuinely contested, and where this piece will not assert a settled number, is exactly how much real-world blocking effectiveness is lost for a typical user in 2026. Google's own post on resuming the Manifest V3 timeline quotes Andrey Meshkov, CTO of the ad-blocking company AdGuard, saying that "ad blockers like us will be able to continue being up to the task and further improve" — a vendor's optimistic framing, not an independent benchmark. Meanwhile, uBlock Origin's own project documentation is clear that it considers Firefox meaningfully more capable than any Chromium-based browser for its purposes, without putting a precise percentage on the gap for Chrome specifically. Independent, rigorously sourced numbers comparing blocking rates between the classic uBlock Origin and its Manifest V3 successors are not something Google, Mozilla, or the uBlock Origin project itself has published in a form this article can point to, so treat any specific "X% fewer ads blocked" figure you see elsewhere as an estimate, not a verified fact.

How Firefox's Manifest V3 Differs From Chrome's

Firefox adopted its own version of Manifest V3, but Mozilla has been explicit that it did not simply copy Chrome's implementation. Mozilla's own extension-developer documentation states plainly that "our implementation diverges where we think it matters and where our values point to a different direction." Concretely, Mozilla's migration guide points to several differences: Firefox kept the older Page Action API and its associated keyboard shortcut rather than folding it entirely into the unified Action API Chromium browsers use, it supports non-persistent background "event pages" as an alternative to service workers, and it applies a different content security policy than Chromium's Manifest V3 does.

Those platform-level differences are part of why uBlock Origin's own documentation continues to recommend Firefox for users who want its full filtering engine, including capabilities like CNAME uncloaking and HTML filtering that the project says Chromium-based browsers simply do not expose to extensions at all, Manifest V3 or otherwise. If maximum ad- and tracker-blocking capability matters more to you than staying on Chrome specifically, Firefox is the browser where that capability gap is documented most directly by the people who build the blocker.

What to Actually Do About It Right Now

If your Chrome ad blocker stopped working, got replaced automatically, or feels less aggressive than it used to, here is the practical state of play:

• Check what's actually installed. Open chrome://extensions and see whether Chrome auto-swapped your old blocker for a Manifest V3 version, such as uBlock Origin Lite, during the 2025 rollout. Many users already have a working replacement without realizing it changed.
• Install uBlock Origin Lite directly if you don't have it. It is the official Manifest V3 successor from uBlock Origin's own developer, not a third-party clone, and it is the closest thing to a direct replacement available on Chrome.
• Know that other reputable blockers (AdGuard, Ghostery, and others) have also rebuilt around declarativeNetRequest and operate within the same Chrome-imposed rule ceilings; none of them can restore the old blocking webRequest model, because Chrome itself no longer offers it to any extension.
• Consider Firefox for maximum filtering strength. If blocking power matters more than staying inside Chrome's ecosystem, uBlock Origin's own project documentation points to Firefox as the browser where its filtering engine runs at full capability.
• Don't chase unofficial "MV2 reviver" extensions or sideloaded old versions. Chrome's Manifest V2 support is gone at the platform level, not just removed from the Store, so workarounds that claim to resurrect classic uBlock Origin on current Chrome either don't work as advertised or require disabling security protections you probably want to keep.
• Keep an eye on Chrome's own extension settings as the browser continues shipping unrelated changes, from version-numbering updates to deeper AI integration like Gemini in Chrome, since Google has shown it will keep adjusting declarativeNetRequest's limits in response to developer feedback.

The short version: Manifest V3 did not end ad blocking in Chrome, but it did end the specific technical approach the most powerful Chrome ad blockers used to rely on. uBlock Origin Lite, AdGuard, and other declarativeNetRequest-based tools are genuine, actively maintained replacements, not downgrades dressed up as replacements — they're just working within a narrower rulebook than their Manifest V2 predecessors did, one that Google has already revised upward more than once and will likely keep adjusting as the Manifest V3 ecosystem matures.

Written byFelix Moreau

Felix Moreau writes Pandromeda's software coverage and how-to guides. He covers Windows, macOS and Linux updates, the apps people rely on, emulators and developer tools, and turns official documentation into clear, numbered steps that work on the current version.

More from Felix MoreauAll Software & Guides coverage