TL;DR
Chrome 150 (June 2026) removed the ExtensionManifestV2Disabled enterprise flag, and Chrome 151 (July 2026) removed the last remaining Manifest V2 escape hatches. That's the real end of MV2. Extensions that filtered network traffic with blocking webRequest — the classic ad blockers like the original uBlock Origin — stop running. Extensions that don't touch the network filtering path keep working exactly as before. A local PDF tool like Convert: Web to PDF never filtered your traffic in the first place, so it's completely unaffected. This post explains which category each of your extensions falls into, how to audit your own shelf in five minutes, and what to switch to if your ad blocker went dark.
The short version: why some extensions broke and yours might not have
The Manifest V3 transition was never about "all extensions." It was about one specific capability: the ability of an extension to sit in the middle of every network request your browser makes and block or rewrite it on the fly. That capability — the blocking webRequest API — is what powered the most powerful content and ad blockers. Manifest V3 removes it and replaces it with a narrower, pre-declared system called declarativeNetRequest.
If an extension needed to inspect and decide about network requests in real time, MV3 changed the ground under its feet. If an extension never did that — and most don't — MV3 is a non-event for it.
By mid-2026, roughly 85% of extensions in the Chrome Web Store had already shipped MV3 versions. The ones making headlines for "breaking" are a small, high-profile slice: the network-filtering power tools. Everything else quietly migrated months or years ago.
So the honest answer to "did my extensions break?" is: probably not, unless you were running an old-style blocking ad blocker. Let's make that concrete.
What actually changed in Chrome 150 and 151
Google spread the MV2 shutdown over many releases so it wouldn't happen all at once. Two mid-2026 milestones closed the book:
- Chrome 150 (June 2026) removed the
ExtensionManifestV2Disabledpolicy flag. This flag was an enterprise-only lever that let managed organizations keep MV2 extensions alive past the consumer deadline. Removing it means even managed Chrome fleets lose the reprieve. - Chrome 151 (July 2026) removed the last MV2-related flags entirely. After this, there is no supported path — consumer or enterprise — to load or run a Manifest V2 extension in mainline Chrome.
For a normal user, the visible effect is simple: any extension that never migrated to MV3 is now disabled and won't turn back on. The Chrome Web Store stopped accepting MV2 submissions long ago, so anything still on MV2 at this point is effectively abandoned or was deliberately holding out.
The two APIs at the center of it
The whole story rotates around a swap of one API for another:
- Blocking
webRequest(MV2): An extension registers a listener that fires on every request. It sees the full request, runs arbitrary code, and returns a decision — allow, block, redirect, modify headers. Maximum power, maximum flexibility, and maximum ability to see everything you load. declarativeNetRequest(MV3): An extension pre-declares a set of rules ("block requests matching this pattern"). Chrome enforces the rules itself; the extension never sees the individual requests. There's a cap on how many dynamic rules an extension can register, though Google raised that cap substantially over the migration period.
The trade-off Google made its argument on: with declarativeNetRequest, an ad blocker literally cannot read your browsing stream, because it never receives the requests — it just hands Chrome a rulebook. That's a genuine privacy improvement in the abstract. The cost is that the most sophisticated, adaptive filtering (the kind that reacts to what a page is doing in the moment) becomes harder or impossible to express as static rules.
Reasonable people disagree about whether the trade was worth it. But mechanically, that swap is the entire reason some blockers broke and your password manager didn't.
Which of your extensions still work? A category map
Here's how to reason about any extension without reading its source code. Ask: does this thing need to intercept and filter my network traffic in real time? If yes, it was at risk. If no, it's fine.
| Extension category | Needs blocking webRequest? | Status after Chrome 151 | Example behavior |
|---|---|---|---|
| Classic ad / content blockers (MV2) | Yes | Broken / disabled | Filtered every request in real time |
| MV3 ad blockers (declarativeNetRequest) | No (uses rule lists) | Works, sometimes with reduced filtering | Pre-declared block rules |
| Password managers | No | Works | Fills forms, reads page fields |
| Local PDF / capture tools | No | Works | Renders the current page locally |
| Screenshot / annotation tools | No | Works | Reads visible DOM / canvas |
| Grammar / writing assistants | No | Works | Reads and edits text fields |
| Tab managers, session savers | No | Works | Manages browser windows/tabs |
| Dark-mode / theme extensions | No | Works | Injects CSS |
| Price trackers, coupon finders | Sometimes | Mixed | Depends on whether they intercept requests |
| VPN / proxy extensions | Sometimes | Mixed | Some used webRequest for routing |
The pattern is clear: the survivors are extensions that operate on the page you're already looking at or on your browser's own UI, not on the stream of requests between you and the internet.
Where Convert: Web to PDF sits
Convert: Web to PDF is squarely in the "operates on the page you're already looking at" camp. It doesn't register a webRequest listener. It doesn't filter, redirect, or inspect your network traffic. It doesn't run a background service that watches what you load.
What it actually does is drive Chrome's own DevTools Protocol to render the page currently in your tab into a real PDF — one with selectable text, clickable links, and embedded fonts, produced by the same print engine Chrome uses for its native "Print to PDF." All of that rendering happens locally, on your machine. There is no server round-trip and no network-filtering surface for MV3 to have deprecated.
That's why the extension is entirely unaffected by the Chrome 150/151 cleanup. There was nothing in its architecture that depended on the API that went away. If you want the specifics of how the local rendering path works, the tool page and the full FAQ lay it out.
Why local tools are structurally immune to this kind of change
There's a broader lesson here worth naming, because it'll matter for the next platform change too, whatever it is.
Extensions that depend on deep, privileged browser hooks are exposed to every platform decision the browser vendor makes. Blocking webRequest was one such hook. When Google decided to narrow it, everything built on top of it was at the mercy of that decision. That's not a knock on those extensions — it's the nature of building on a powerful, vendor-controlled API.
Extensions that do their work locally, on the rendered page, using stable, general-purpose APIs (like the DevTools Protocol that Chrome maintains for its own developer tools) have a much smaller blast radius. They're not asking the browser for special permission to sit in the middle of your traffic. They're asking it to do something it already does for everyone — render a page, print a page — and capturing the result.
This is the same reason a tool that processes everything on-device tends to outlast tools that route your data through a server: fewer dependencies, fewer things that can be taken away, fewer places your data can leak. It's the philosophy behind why a PDF converter should never upload your files, and it's exactly why the MV3 endgame didn't touch this category.
How to audit your extension shelf in five minutes
You don't need to guess. Here's a concrete pass:
- Open
chrome://extensions. Toggle on Developer mode (top right). This surfaces extra detail, including manifest versions in some cases and the extension's ID. - Look for anything greyed out or flagged. After Chrome 151, MV2 extensions appear disabled with a note that they're no longer supported. Those are your casualties.
- For each active extension, ask the network question. Is this thing's whole job to filter or reroute traffic? Ad blockers, some privacy tools, some VPN/proxy extensions. Those are the ones to double-check are on MV3 versions.
- Check the "Details" page for permissions. Extensions still requesting broad host access plus network capabilities are the ones most affected by the API changes. A tool that only needs
activeTaborscriptingon the current page is in the safe camp. - Cross-reference with the Web Store. Open each extension's store listing. If the developer shipped an MV3 update, you'll usually see recent version activity. If the listing is gone or hasn't been updated in a very long time, treat it as abandoned.
- Remove the dead weight. Disabled MV2 extensions aren't doing anything anymore — uninstall them. Every extension you keep is attack surface; keep only what earns its place.
If you run several browsers, note that this all applies to the whole Chromium family — Chrome, Edge, Brave, Opera, Vivaldi, Arc all share the engine and the MV3 timeline (Brave has done its own extra work on ad blocking outside the extension system, which is a separate story). Firefox and Safari are on different tracks entirely and aren't part of this cleanup.
What to do if your ad blocker died
If you were running a classic MV2 blocker and it went dark, you have a few honest options. Let's be straight about the trade-offs rather than pretend they don't exist.
Option 1: Switch to an MV3-native blocker
Most major ad blockers shipped MV3 versions well before the deadline, built on declarativeNetRequest. For the vast majority of everyday browsing, these block the vast majority of ads and trackers. The difference from the old blocking-webRequest engines shows up mainly in edge cases: sites that adapt their ad delivery aggressively, or highly customized filter setups. For most people, an MV3 blocker is a near-seamless swap.
Option 2: Move blocking below the browser
Because MV3 constrains browser-extension filtering specifically, some people moved their blocking to a layer the browser doesn't control: DNS-level blocking (a filtering DNS resolver) or a network-wide blocker on their router or a small home server. These aren't affected by Chrome's extension policy at all because they operate before traffic ever reaches the browser. The trade-off is setup complexity and less granular, per-page control.
Option 3: Use a browser with built-in blocking
Some Chromium browsers ship their own ad/tracker blocking that lives in the browser itself, not in an extension, and therefore isn't governed by the MV3 extension rules. If you're already a heavy blocker user, this is worth evaluating.
Whatever you choose, don't panic-install the first "ad blocker" you find in a search. A dead ad blocker is a magnet for copycat listings, and a network-filtering extension is exactly the kind you least want to get wrong. Check the developer, the review history, and the permissions before installing.
A note on trust and permissions after the shakeout
One quiet upside of a platform transition is that it forces a re-examination. If you're going to reinstall or replace extensions anyway, it's a good moment to apply a simple rule: prefer tools that ask for the least.
An extension that needs to read and filter all your network traffic is asking for a lot, and sometimes that's genuinely justified (a real ad blocker needs to see requests, or rules about requests). But a surprising number of extensions ask for broad access they don't actually need. The MV3 world makes the network-filtering ask more visible and more constrained, which is healthy.
For the categories that don't need network access at all — PDF tools, screenshot tools, readers — the right expectation is: it should touch the page you're on and nothing else, and it should do its work without sending your data anywhere. Convert: Web to PDF, for example, does its entire job on the current page, renders locally, and sends exactly one anonymous install-token ping after a conversion — no URL, no page content. That's the profile to look for: minimal permissions, local processing, no data exfiltration.
Frequently asked questions
Did Manifest V3 kill all ad blockers?
No. It killed the old-style ad blockers built on blocking webRequest, and it constrained what the new ones can do. MV3-native ad blockers built on declarativeNetRequest still work and still block the large majority of ads for most users. The debate is about the hardest edge cases, not about ad blocking disappearing.
Will Convert: Web to PDF stop working because of Manifest V3?
No. It never used the network-filtering APIs that MV3 changed. It renders the current page into a real PDF locally using Chrome's DevTools Protocol and print engine. Nothing in the Chrome 150 or 151 cleanup touches that path.
How do I tell if one of my extensions is affected?
Ask whether its core job is to intercept or filter your network traffic in real time. Ad blockers, some privacy tools, and some VPN/proxy extensions did that. Password managers, PDF tools, screenshot tools, readers, and theme extensions don't — those are unaffected. Then check chrome://extensions for anything Chrome has disabled as unsupported.
Does this affect Edge, Brave, Arc, Opera, and Vivaldi?
Yes, because they share Chromium and the same MV3 timeline. Firefox and Safari are on separate paths and aren't part of this specific cleanup. Convert: Web to PDF works across the Chromium family (Chrome, Edge, Brave, Arc, Opera, Vivaldi) — just not Firefox or Safari.
My extension still shows up but is greyed out. What happened?
That's Chrome flagging a Manifest V2 extension it can no longer run after the cleanup. It's disabled and won't re-enable. If the developer shipped an MV3 replacement, update to that from the Web Store; otherwise, uninstall it and find a maintained alternative.
Is a local tool always safer than a cloud tool during platform changes?
Not automatically, but structurally it has a smaller blast radius. A local tool depends on fewer vendor-controlled hooks and doesn't route your data through a server, so there's less that a platform change — or a breach — can take away or expose. That's a big part of why the PDF category sailed through MV3 untouched.
Should I do anything right now if all my extensions still work?
Just a quick audit. Open chrome://extensions, remove anything disabled or abandoned, and glance at the permissions on what's left. Keeping only maintained, minimal-permission extensions is good hygiene regardless of MV3.
Bottom line
The Manifest V3 endgame in mid-2026 was loud because it broke a specific, beloved category — the old blocking-webRequest ad blockers — not because it broke extensions in general. Around 85% of the store had already migrated. The extensions that survived are the ones that operate on the page you're looking at or your browser's own UI, not on the stream of traffic between you and the web.
That's the whole reason a local, non-network-filtering tool like Convert: Web to PDF kept working without a hiccup: it renders the current page into a real, selectable-text PDF locally through Chrome's own engine, with no dependency on the API that went away. Audit your shelf, replace what died with maintained MV3 alternatives, and lean toward tools that ask for the least and process on-device. That's the profile that outlasts platform changes — this one and the next.