If your ad blocker suddenly feels weaker than it used to, you’re not imagining it — but the popular explanation is wrong. Manifest V3 is the technical rulebook Chrome (and every other Chromium-based browser) now uses to decide what an extension is allowed to do, and it took away the single most powerful tool ad blockers relied on. That’s a real change with real consequences. It is not, however, a ban.
This guide explains what a browser extension and a “manifest” actually are, exactly what technical capability Manifest V3 removed, why that specifically hurt blockers like uBlock Origin, and both sides of the fight over why it happened — Google’s stated engineering rationale and the critics’ pointed reply that Google also happens to be the world’s largest advertising company. We’ll also cover the actual 2026 rollout dates, because a lot of the panic online is a year or two out of date.
What’s a Browser Extension, and What’s a “Manifest”?
A browser extension is a small add-on program — an ad blocker, a password manager, a grammar checker, a coupon finder — that installs into your browser and gets special permissions beyond what a normal website has. Depending on what it asks for, an extension can read the pages you visit, see the network requests your tabs make, and in some cases modify what loads before you ever see it.
A manifest is the extension’s configuration file: a small text document declaring what the extension is allowed to do and which browser APIs (Application Programming Interfaces — the hooks a program uses to ask the browser to do something) it’s permitted to call. “Manifest V2” and “Manifest V3” are two successive generations of that rulebook, and every extension in the Chrome Web Store must declare which one it targets. Chrome — and every browser built on the open-source Chromium project, including Edge, Brave, Opera, and Vivaldi — has spent the last several years migrating extensions from V2 to V3.
webRequest vs. declarativeNetRequest: What Actually Changed
The whole controversy comes down to one API being swapped for a much more limited one.
Under Manifest V2, powerful extensions used an API called webRequest in “blocking” mode. It let the extension’s own code sit in the middle of your browsing traffic in real time: inspect every network request as it happened, and decide — with arbitrary custom logic — whether to block it, redirect it, or rewrite it. This is what made full uBlock Origin so effective. It could react to almost anything, including patterns nobody had anticipated when the extension was written.
Manifest V3 replaces that with declarativeNetRequest (DNR). Instead of the extension watching your live traffic and deciding what to do on the fly, it now hands the browser a static list of rules in advance — “if a request matches pattern X, block or modify it in way Y” — and the browser itself executes those rules. The extension’s own code never touches the traffic content. That is a meaningful security improvement (more on that below), but it also means the extension can only do what it pre-declared. It can’t inspect a response, adapt to a new anti-blocking trick on the fly, or run custom logic against traffic it’s never seen before.
Why the Most Powerful Ad Blockers Got Weaker
This is exactly why uBlock Origin — long considered the gold standard — had to release a scaled-down sibling for Manifest V3: uBlock Origin Lite (uBOL). It isn’t a different philosophy or a lazier rewrite; it’s an architectural consequence of losing webRequest.
Full uBlock Origin does procedural filtering: dynamic, code-driven techniques like inspecting response content, defeating scripts built to detect and disable ad blockers, and “uncloaking” trackers that hide behind a site’s own domain name (CNAME cloaking) so they look like first-party traffic. uBlock Origin Lite, built for declarativeNetRequest, is “declarative-only”: it ships a fixed rule set — based on the same well-known filter lists like EasyList and EasyPrivacy — that the browser enforces mechanically, with no background process reading your traffic. It still blocks the overwhelming majority of conventional banner, video, and pop-up ads, since most ads are blocked by simple pattern matching against known ad-serving domains, which DNR handles fine. What’s genuinely lost is the dynamic, procedural layer: out-maneuvering a site’s anti-adblock script in real time, or catching a newly cloaked tracker the moment it appears.
Manifest V3 also imposes hard numeric limits on how many rules a declarativeNetRequest ruleset can contain — caps Google has revised upward more than once after developer pushback. The exact current figure moves often enough that we won’t print a number here that might already be stale; check Chrome’s extension developer documentation if the ceiling matters to you.
Google’s Case for Manifest V3: Security, Performance, Privacy
Google’s own public migration documentation frames Manifest V3 primarily as a security change, and the argument has real merit. Under the old webRequest-blocking model, a malicious or compromised extension could run arbitrary code with a front-row seat to everything you did online — every page, every form field, every login. Manifest V3 tightens the Content Security Policy extensions must follow and bans remotely hosted or eval‘d code, closing a well-documented path malware used to sneak logic past the Chrome Web Store’s review process after an extension was already approved and installed on millions of machines.
There’s a performance case too: an extension running its own code against every network request on every page adds real overhead. Handing the matching work to the browser’s own optimized engine, working from a pre-declared list, is measurably faster and lighter on memory and battery.
And there’s a privacy case, distinct from the security one — worth being precise about, since security and privacy are not the same axis even though they’re often lumped together. webRequest-blocking let an extension’s code see your full traffic to decide what to do with it. declarativeNetRequest never shows the extension that content at all — the browser applies the rules internally, so even a well-behaved extension is architecturally blocked from harvesting your browsing data through this channel, regardless of its author’s intent.
The Conflict-of-Interest Critique: An Ad Company Writing the Rules
Here’s the other side, and it’s a fair one, not a conspiracy theory. Alphabet — Google’s parent company — is the largest digital advertising company on Earth, earning the large majority of its revenue from ads. Critics point out the obvious optics: the company writing the technical rules for how effectively ad blockers can operate is also the company with the single largest financial stake in ads not being blocked. That doesn’t make Google’s stated security rationale false — the CSP tightening and remote-code ban are real and defensible on their own terms. But the rationale and the outcome happen to align suspiciously well with Google’s business interests, and reasonable people are entitled to weigh that when deciding how much good faith to extend.
It also matters who controls the decision. Chromium is nominally an open-source project anyone can contribute to, but Google authors most of the code and sets the extension platform’s direction — including for the many other Chromium-based browsers that inherit whatever Google decides for the underlying engine. A few say they’ll keep supporting stronger blocking outside the standard extension APIs — Brave, for instance, is understood to maintain its own built-in filtering engine independent of any installed extension, though we’d flag that as our general understanding rather than something freshly verified against Brave’s current documentation; check their blog before relying on it. The neutral framing: less “Google banned ad blockers,” more “one company’s engineering choices, made for defensible technical reasons, also reshape how much power the whole web-browsing ecosystem has to resist that same company’s business model.”
Myth-Check: Manifest V3 Did Not “Ban” Ad Blockers
This is the single most important correction in this article, so it deserves its own section. Headlines and social media posts have repeatedly claimed Chrome “banned ad blockers.” It didn’t. Ad blocking as a category works fine under Manifest V3 — uBlock Origin Lite, AdGuard, and other DNR-based blockers are live in the Chrome Web Store right now, actively blocking the vast majority of conventional ads and trackers on ordinary websites.
What’s true, precisely: the most sophisticated, adaptive filtering — inspecting responses on the fly, defeating anti-adblock countermeasures the moment they appear, uncloaking trackers hiding behind first-party domains — is no longer possible, because that requires exactly the live-traffic inspection webRequest-blocking provided and declarativeNetRequest deliberately doesn’t. If you never noticed a difference switching from full uBlock Origin to uBlock Origin Lite, that’s not surprising — most sites don’t run anti-adblock scripts or CNAME-cloaked trackers, so the two behave almost identically most of the time. The gap shows up against the aggressive tracking-and-anti-blocking arms race, not your average banner ad.
Where Things Stand in 2026 — Dates and What to Do
The migration has been gradual, and the dates matter if you’re trying to understand why your setup looks the way it does right now. Chrome stopped accepting brand-new Manifest V2 extension submissions to the Web Store back in 2022. By March 2025, Chrome had disabled Manifest V2 extensions by default across all channels, though a manual re-enable toggle still existed briefly, and a temporary enterprise policy (ExtensionManifestV2Availability) let organizations delay the transition. As of Chrome 138 in July 2025, Manifest V2 extensions are fully disabled with no ordinary re-enable option left, and that enterprise exemption expired shortly after. Google has scheduled the last step for August 31, 2026: the date all remaining Manifest V2 extensions are removed from the Chrome Web Store entirely. Read this after that date, and MV2 extensions are gone from the store outright, not just disabled in your browser.
Practically, if you’re still relying on an old Manifest V2 ad blocker in Chrome, it almost certainly stopped working months ago — check for an uBlock Origin Lite–style DNR successor, or consider a Chromium-based browser with its own native filtering layer if adaptive blocking matters enough to leave Chrome over. It’s worth remembering this is a Chromium/Chrome story specifically: Firefox, which isn’t built on Chromium, made its own choice and is widely reported to have kept the more capable webRequest blocking API — which is why full uBlock Origin is often described as running best there.
❓ Frequently Asked Questions
Did Manifest V3 ban ad blockers in Chrome? No — the most common misconception here. Ad blockers built for Manifest V3, like uBlock Origin Lite, are live in the Chrome Web Store and block the large majority of conventional ads and trackers. What was removed is the older webRequest-blocking API’s dynamic, code-driven filtering, not ad blocking as a category.
Why did uBlock Origin need a “Lite” version? Because Manifest V3 replaced the powerful webRequest-blocking API with the more limited declarativeNetRequest, which only enforces a pre-declared, static rule list rather than letting the extension inspect live traffic with custom code. uBlock Origin Lite is the required rebuild for that new, more restricted API — not a lesser effort by its developer.
What exactly is lost when you switch to a Manifest V3 ad blocker? Mainly dynamic and procedural filtering: inspecting response content, adapting in real time to anti-adblock scripts, and uncloaking trackers hidden behind a site’s own domain (CNAME cloaking). Straightforward domain- and pattern-based blocking, which covers most ordinary ads, still works well under the new model.
Why did Google make this change? Google’s stated reasons are security, performance, and privacy: Manifest V3 bans remotely hosted and eval‘d extension code, closing a path malware used to exploit approved extensions; it shifts matching work to the browser’s own faster engine; and it structurally prevents extensions from viewing raw traffic content. Critics counter that Google, the world’s largest advertising company, has an obvious financial interest in weaker ad blocking — a conflict of interest worth weighing alongside the technical rationale.
When does Manifest V2 fully disappear from Chrome? Chrome 138 (July 2025) fully disabled Manifest V2 extensions for ordinary users, with no re-enable option left. Google has scheduled August 31, 2026 as the date all remaining Manifest V2 extensions are removed from the Chrome Web Store entirely — after that, they won’t be installable or updatable from the store at all.
📚 Further Reading
- What Is Chromium? The Open-Source Project Behind Chrome — the foundation this entire extension platform is built on.
- Is Google Chrome Private? What Really Happens to Your Data — how the privacy question here fits the bigger picture of what Chrome does with your data.
- Who Controls Chromium? — the power-concentration story behind decisions like Manifest V3.
- Browser History, Cookies, Cache, and Saved Data Explained — the broader picture of what your browser tracks and stores.
📚 Recommended Resources
Disclosure: some links below are Amazon affiliate links. If you buy through them, I earn a small commission — at no extra cost to you — which helps keep this site running.
The Age of Surveillance Capitalism
Shoshana Zuboff · Book · ~$22 on Amazon
The definitive account of how advertising-driven tech companies turned tracking into a business model — essential context for understanding why the company writing Manifest V3’s rules also happens to be the world’s largest ad seller.
Data and Goliath
Bruce Schneier · Book · ~$18 on Amazon
A clear-eyed look at surveillance, data collection, and the security-versus-privacy trade-offs that run through this article — from a security expert who explains exactly why “more secure” and “more private” aren’t automatically the same thing.