The way ad blockers work in Chrome has fundamentally changed, and 2026 is the year the old way finally ended. With Manifest V3 now fully enforced across every Chromium browser, extensions can no longer inspect and block network requests in real time using the old webRequest API. They must instead register declarative rules that the browser engine evaluates on their behalf, a shift that improves security and performance but hands Google, which controls Chromium, more say over what content can be blocked.
- Manifest V3 is Chrome's extension platform, and its 2026 enforcement removes the blocking webRequest API that powerful ad blockers relied on.
- Blockers now use declarativeNetRequest: they hand the browser a rule list, and the engine decides what to block, rather than the extension seeing each request.
- The change affects every Chromium browser, Edge, Brave, Opera, Vivaldi and Arc, not just Chrome, because they all share the engine.
- Google frames it as security and performance; critics note it also gives the browser vendor more control over the filtering that competes with its own ad business.
What is Manifest V3 and what changed?
Manifest V3 is the specification that defines what Chrome extensions can do and how. Its most contested change removes the blocking form of the webRequest API, the mechanism that let an extension observe every network request a page made and decide, in code, whether to block it. That capability is what made content blockers like the classic uBlock Origin so powerful and flexible. In its place, V3 offers declarativeNetRequest: instead of running code on each request, an extension registers a set of static or dynamic rules ahead of time, and the browser engine applies them. The engine, not the extension, now does the blocking, and the extension no longer sees the traffic. 2026 is when the transition period ended and enforcement became universal across Chromium.
RelatedInterop 2026 Makes Anchor Positioning Work Everywhere
Why did Google make this change?
The official case is security and performance, and it is not baseless. An extension that can read every request you make is a serious privacy and attack surface, and a malicious or compromised blocker could exfiltrate browsing data or slow every page load. Declarative rules run inside the engine, so the extension never touches your traffic and cannot stall it. Those are real benefits. The uncomfortable counterpoint is who benefits most: the same company that writes the rules of the extension platform also runs the largest advertising business on the web, and moving blocking control into the engine it governs gives it structural influence over the tools that block its ads. Google can point to genuine security wins, and critics can point to the conflict of interest, and both are correct at once.
| Aspect | Manifest V2 | Manifest V3 |
|---|---|---|
| Blocking model | Live request filtering | Declarative rules |
| Who decides | The extension | The browser engine |
| Sees your traffic | Yes, every request | No |
| Rule flexibility | Arbitrary code logic | Rule-list limits |
| Security surface | Larger | Smaller |
| Vendor control | Low | Higher |
For most users, well-maintained blockers still work: the major ones shipped V3-compatible versions and slimmer "Lite" variants that lean on declarative rules. The tradeoff shows up at the edges, in the advanced, dynamic filtering that live code could do and static rules cannot express as cleanly. The practical result is that everyday blocking is fine, while the power-user ceiling is lower than it was.
Who is actually affected, and what are the options?
Anyone on a Chromium browser, which is most of the web, is affected, because Edge, Brave, Opera, Vivaldi and Arc all inherit the engine and its rules. Users who want maximum blocking flexibility have two realistic escape hatches. The first is Firefox, the last major browser on the independent Gecko engine, which kept a compatible version of the powerful blocking API. The second is Chromium browsers like Brave that build their own blocking into the engine itself, sidestepping the extension limits by not relying on an extension for the core job. For everyone else, the answer is simpler: keep your blocker updated, accept that the engine now does the work, and know that the ceiling on what an add-on can block has quietly come down.
RelatedWebGPU Goes Cross-Browser, Unlocking In-Browser AI
- Blocker parity. Watch whether declarative-rule blockers close the gap with the old dynamic filtering, or whether edge cases keep slipping through.
- Firefox pull. Gecko kept the powerful API. Watch whether power users migrate for blocking freedom.
- Engine-level blocking. Watch Brave and similar builds double down on native blocking that ignores the extension limits.
- Regulatory eyes. The ad-business conflict is drawing scrutiny. Watch antitrust interest in who controls web filtering.
Our take
Manifest V3 is the clearest case in browsers of a change that is simultaneously a real security improvement and a real concentration of power, and pretending it is only one of those is dishonest. Moving request handling into the engine genuinely shrinks the attack surface and speeds up page loads, and most people will never notice their blocker changed. But the structural fact remains that the company setting the rules for what extensions may block is the company that sells the ads those extensions exist to block, and enforcing that across every Chromium browser at once removes the pressure valve of choice. The healthy response is not outrage, it is diversity: the fact that Firefox kept the powerful API and that engine-level blockers exist is exactly why the web needs more than one engine. Convenience and control are trading places here, and 2026 is the year that trade became permanent for most of the web.
- OfficialChrome Manifest V3 migration docs , the platform change in Google's words
- ReferenceMDN WebExtensions , Firefox's approach to the blocking API
- ReferenceChrome at I/O 2026 , current extension-platform direction
Original analysis by GenZTech. Figures current as of July 2026. Source: developer.chrome.com
