Manifest V3 is the current extension platform for Chromium browsers. Google announced it in 2018, shipped it in 2021, and finished phasing out Manifest V2 for regular Chrome users in 2025, with a temporary enterprise-policy escape hatch that has also now closed. Because Chrome's extension platform is inherited by Edge, Opera, Brave, and most other browsers, the decision reshaped content blocking for the large majority of desktop web users.
The Change That Matters: Who Sees the Request
Under Manifest V2, a content blocker could register a blocking webRequest listener. Every network request the page made was handed to the extension's own code, which decided in real time: allow, block, or modify. This is what let uBlock Origin apply over a hundred thousand filter rules, evaluate them with arbitrary logic, and update its lists as often as the maintainers pushed changes.
Manifest V3 removes blocking webRequest for normal extensions and replaces it with declarativeNetRequest. The extension no longer sees the request stream. Instead it declares a rule list up front, and the browser itself applies the rules. Extensions still exist, but for the core blocking decision they have been demoted from programs to configuration files.
The declarative model comes with hard budgets. An extension is guaranteed 30,000 static rules, with more available from a global pool shared across all installed extensions, and regular-expression rules are capped far lower. Rules can be enabled and updated dynamically only within tight limits. Complex filter logic, the kind that inspects a request in context, has no equivalent at all.
The Case Google Made
Google's stated rationale is worth taking seriously, because parts of it are true. An extension that can read every network request is an enormous trust liability: malicious and acquired extensions have abused exactly that power to harvest browsing history at scale. Under declarativeNetRequest, a filter extension never sees your traffic, so a compromised ad blocker can no longer double as spyware. Moving evaluation into the browser also has performance benefits and kills a class of extension-caused slowdowns.
The criticism is not that these benefits are fake. It is that the rule budgets and the removal of runtime logic were set at levels that hollow out advanced content blocking, and that the company setting those levels earns most of its revenue from the advertising being blocked. Mozilla adopted Manifest V3 for compatibility but kept blocking webRequest available, which demonstrates the two goals were separable: you can have the new platform and still permit powerful blockers. Chrome chose not to.
What Was Actually Lost
| Capability | Chrome MV2 (retired) | Chrome MV3 | Firefox today |
|---|---|---|---|
| Rule capacity | Unbounded (memory-limited) | 30,000 guaranteed static + shared pool | Unbounded |
| Per-request logic in extension code | Yes | No | Yes |
| Instant filter-list updates | Any time | Dynamic rules only, tightly capped | Any time |
| uBlock Origin (full) | Supported | Removed; uBO Lite only | Supported |
| Extension can read your traffic | Yes (the trade-off) | No | Yes, if granted |
The practical casualties are the advanced features. Dynamic per-site filtering, procedural cosmetic rules that hide elements based on page structure, and rapid response to new ad-tech countermeasures all depended on running code, not declaring rules. Filter-list maintainers now negotiate with a budget: when a list update lands, it competes against the caps rather than simply shipping. That matters because content blocking is an arms race in the literal sense. Ad-tech vendors probe blockers and rotate domains and techniques on a cycle of days, and the blocker's historical advantage was that a list update reached users in hours. Under the declarative model, the deep countermeasures ship with the extension itself, which means they wait on a store review before they reach anyone.
None of this is new territory, for what it is worth. Safari moved to a declarative content blocker API back in 2015, with its own rule caps, and the same trade was made there: better containment of extensions, weaker blocking at the margins. Chrome's version of the trade simply matters more, because Chrome is where most of the web's users are.
Raymond Hill declined to ship a degraded uBlock Origin under the same name. The MV3 version is a separate extension, uBlock Origin Lite, described plainly as less capable. Whatever you think of the platform change, that refusal to quietly weaken a security tool while keeping its reputation is the right instinct, and it is rarer than it should be.
Where That Leaves You
Content blocking earns its place in a privacy toolkit on the merits: ads are the delivery mechanism for most commercial tracking, for real-time bidding data flows, and periodically for malware. Choosing where blocking happens is now a real decision with real options:
- Firefox with uBlock Origin remains the strongest widely available combination, because Mozilla kept the APIs the full extension needs. If content blocking is a priority, this is the direct answer.
- uBlock Origin Lite on Chrome is a competent baseline blocker. It handles the common filter lists within the caps. What you give up is the dynamic and surgical end of the toolset.
- Browsers with native blocking engines, such as Brave, implement filtering in the browser core and are not constrained by extension APIs at all.
- Network-level blocking through Pi-hole or a filtering DNS resolver covers every device in the house and does not care what Chrome permits. It cannot do cosmetic filtering, so it complements rather than replaces a browser blocker.
The larger lesson generalizes past ad blocking. When a privacy tool lives inside a platform, it operates at the platform owner's pleasure, under rules the owner can rewrite. That is not a reason to refuse platform tools. It is a reason to notice where the incentives point, and to keep at least one layer of your defenses, whether DNS filtering or your choice of browser, outside the platform whose business model you are defending against.