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.
How ad blocking changed from Manifest V2 to V3 Under Manifest V2 the extension inspected every request and decided what to block. Under V3 the extension only supplies rules and the browser engine does the blocking. Manifest V2 Manifest V3 Page requests a resource Extension inspects it Extension decides: block? Extension registers rules Browser engine evaluates Engine blocks per rules Extension sees every request Engine holds the control genztech.blog
Fig 1 The heart of the change: under V2 the extension saw each request and decided; under V3 the extension only supplies a rule list and the browser engine does the blocking, moving control from the add-on to the vendor.

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.

AspectManifest V2Manifest V3
Blocking modelLive request filteringDeclarative rules
Who decidesThe extensionThe browser engine
Sees your trafficYes, every requestNo
Rule flexibilityArbitrary code logicRule-list limits
Security surfaceLargerSmaller
Vendor controlLowHigher

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

What to watch · 2026
  • 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.

Primary sources

Original analysis by GenZTech. Figures current as of July 2026. Source: developer.chrome.com