Manifest V2 Is Gone From the Chrome Web Store: What Broke

On August 31, 2026, Google finished the job it started years ago: every remaining Manifest V2 extension listing is gone from the Chrome Web Store’s search results and catalogue. Not deprioritized, not flagged with a warning banner. Gone. If you or a client depend on a browser extension that never made the jump to Manifest V3, the reinstall path just closed.

What happened to Manifest V2 on August 31

Google deleted the last Manifest V2 extension listings from the Chrome Web Store’s search index and catalogue. Anyone searching the store now finds zero MV2 results, no matter how popular the extension used to be. If it hadn’t migrated to Manifest V3 by that date, it isn’t discoverable anymore, full stop.

This is the final phase of a deprecation timeline Google published years back, and it’s been telegraphed the whole way: install warnings, then a block on new installs for most users, then this. The surprising part for a lot of teams isn’t that it happened. It’s that they hadn’t checked which of their extensions were still running on the old spec.

Who feels this, and how

Three groups feel this differently, and the difference matters if you’re triaging what to fix first.

End users with an MV2 extension already installed on Chrome 138 or an earlier build keep it. It runs. Chrome doesn’t reach into an existing install and kill it. What they lose is the update channel and the reinstall option. The extension is frozen at whatever version it was on when the purge hit, and if that install ever gets removed (a fresh OS image, a new laptop, a corporate re-provision), there’s no getting it back from the store.

Businesses running client-specific extensions are in a worse spot. Agencies build these constantly: a Salesforce sidebar for one client, a login bridge into an internal portal for another. We’ve shipped both kinds, and nobody thinks about the manifest version again once the extension is working. If that extension is still declaring "manifest_version": 2, it’s not going to fail loudly. It’s going to sit fine on the machines that already have it, then quietly fail to reach anyone new, and nobody notices until a new hire can’t install it or IT reimages a laptop.

Developers of anything still shipping on MV2 lost their distribution channel entirely. There’s no submitting an update to an MV2 listing anymore because the listing doesn’t exist.

uBlock Origin’s Manifest V2 build, specifically

The one that got the most attention is uBlock Origin’s MV2 build, and it’s worth being precise about what changed instead of repeating the “ad blocking is dead” headline that’s floating around.

uBlock Origin stayed on Manifest V2 for years after Chrome pushed everyone else toward V3, for a real technical reason: MV3’s declarativeNetRequest API caps the number of dynamic rules an extension can register, and a filter-list-based blocker like uBlock Origin can easily exceed that cap once you stack multiple subscription lists (EasyList, EasyPrivacy, regional lists, and whatever custom rules a user adds). The MV2 build used the old blocking webRequest API, which let it inspect and block requests with no such ceiling.

That MV2 build is gone from the store now, same as everything else. What’s still available is the MV3-compatible version, commonly distributed as uBO Lite (with community forks like uBO Minus extending its filtering), and it works. It’s just not a drop-in replacement in behavior. Static rule sets pull from precompiled rulesets rather than live filter matching, and users who relied on aggressive custom dynamic filtering will notice the ceiling. Call it a real downgrade in flexibility, not a total loss of ad blocking. If a client asks “is my ad blocker broken,” the honest answer is “it’s a different, more constrained tool now,” not “no.”

The MV3 tradeoff, without the corporate framing

Google’s stated reasoning for MV3 has real substance to it. Service workers instead of persistent background pages cut down on extensions that sit in memory doing nothing useful. The restriction on remotely fetched and executed code closes a genuine supply-chain hole: an extension can’t quietly pull down new JavaScript post-review and run it, which was a real vector for extensions getting sold and then turned malicious after the fact. That part of the pitch holds up.

Where it gets more complicated is exactly the use case uBlock Origin represents: anything that needs to inspect or react to network traffic in real time, at scale, based on rules that change dynamically. declarativeNetRequest trades that flexibility for a security and performance win Chrome controls end to end, which is the same tradeoff that shows up in Chrome’s wider security release cadence. For a simple redirect rule or a fixed blocklist, that’s a fair trade. For a power-user ad blocker with tens of thousands of rules and users who tune it constantly, it’s a genuine functional regression dressed up as a security improvement. Both things are true at once, and pretending otherwise doesn’t help anyone deciding what to do about it.

What to actually do about it

Start by finding out what you’re running. Open chrome://extensions, turn on developer mode, and check the manifest version listed under each extension’s details, or, if you maintain the source, grep for "manifest_version" in every manifest.json across your projects and client repos. Anything still on 2 needs a decision this quarter, not “eventually.”

For an internal or client-specific extension still stuck on MV2, the fix isn’t exotic: it needs to be rebuilt against the MV3 architecture, which has been stable and documented since the transition started. If your team is doing that rebuild, the mechanics (service workers replacing background pages, chrome.alarms replacing long-running timers, declarativeNetRequest replacing blocking webRequest, storage quotas, permission scoping) haven’t shifted since launch. Our full Manifest V3 guide walks through the actual code changes if you’re rebuilding one from scratch. Pair that with keeping the browser itself current; the same Chrome 152 security release that patched 327 issues this cycle is a reminder that an extension running on a stale, unpatched Chrome install is a bigger risk than the manifest version itself.

If you’re the one relying on an extension rather than building it, the practical move is smaller: confirm it’s still receiving updates (check its Web Store page; an MV3-compatible listing means it’s fine) and don’t wait for a machine refresh to find out the hard way that an old favorite can’t come back.

The bottom line

Manifest V2 didn’t get slowly deprecated into irrelevance. It got a hard stop, on a specific date, with the listings deleted rather than merely hidden. Existing installs survive on borrowed time. Everything else (new installs, reinstalls, updates) is done. If any extension your business depends on hasn’t made the move, this is the week to find out, because the store isn’t going to tell you. It’s just going to have nothing there when someone goes looking.