The manifest v2 removal completes on August 31, 2026, when Google deletes every remaining Manifest V2 extension from the Chrome Web Store. It is the last dated milestone in a deprecation that has been running since 2022, and it is being covered almost everywhere as the moment your favorite extensions stop working.
That framing is a year late. Manifest V2 extensions in Chrome stopped working in July 2025. What ends on August 31 is not execution, it is supply: the listing, the download, the reinstall, and the channel that other Chromium browsers have quietly been sourcing from. That is a smaller story for the average Chrome user and a considerably larger one for anyone running a Chromium fork, managing a fleet, or maintaining an extension. This piece covers what the date actually changes, the sequence that got us here, where the enterprise exemption went, why the forks are the real exposure, what Manifest V3 does and does not allow, and what is worth doing this week. For the wider picture of how browsers are changing underneath users, see our 2026 agentic browser landscape.
What the manifest v2 removal changes on August 31
Google’s own Manifest V2 support timeline states the outcome in one line: "All remaining Manifest V2 extensions are removed from the Chrome Web Store."
The same page states what survives: "Manifest V2 extensions installed on Chrome 138 or earlier will remain installed, but will be unable to receive any updates and cannot be reinstalled from the Chrome Web Store once removed from Chrome."
Read those together and the scope becomes clear. If you are on current Chrome, nothing changes for you on August 31, because your Manifest V2 extensions were already disabled. If you are deliberately pinned to Chrome 138 or earlier, your extensions keep running, they stop receiving updates, and you cannot get them back if you reinstall your machine. And if you build extensions, your artifact and its listing history disappear from the store on that date.
The practical loss is the store as an archive. A Manifest V2 extension that is not mirrored somewhere else on August 30 is, for most people, gone on September 1.
The sequence that actually got us here
The timeline matters because it explains why the coverage and the reality have drifted apart. Google’s page dates each stage.
| Date | What happened |
|---|---|
| January 2022 | Store stopped accepting new public or unlisted MV2 extensions |
| June 2022 | Store stopped accepting new MV2 extensions marked private |
| June 3, 2024 | Warning banners on Beta, Dev, and Canary; Featured badges stripped from MV2 extensions |
| October 9, 2024 | Gradual disabling begins on stable, with users still able to re-enable |
| March 31, 2025 | MV2 disabled by default on all channels, re-enabling still possible |
| July 24, 2025 | Chrome 138: MV2 disabled for all users, re-enabling no longer possible |
| August 31, 2026 | All remaining MV2 extensions removed from the Chrome Web Store |
The load-bearing date for most people was July 24, 2025, thirteen months ago. That is when the switch became one-way. Everything since then has been cleanup. Trade coverage of the final date, including 9to5Google’s report when Google first shared it in July, has been accurate about the date while the aggregate impression left by the headlines has not.
This is worth flagging on its own terms. A deprecation executed slowly enough produces a final milestone that reads as dramatic and lands as administrative, and the reporting tends to peak at the wrong moment.
The enterprise exemption already expired
For most of the deprecation there was a documented escape hatch: the ExtensionManifestV2Availability policy, which let managed Chrome installations keep running Manifest V2 extensions after consumer Chrome had turned them off.
That exemption ran out. Per Google’s timeline, the policy covered enterprise users until June 2025, Chrome 138 is the final version that honors it, and Chrome 139 removed support entirely for all users. Any managed fleet that was relying on the policy has been out of runway for over a year.
If you inherited a fleet and have not audited this, the useful question is not whether the policy is set. It is whether anything in your environment is pinned to Chrome 138 or earlier specifically to keep an extension alive, because that pin is now a security decision rather than a compatibility one. Pinning a browser a year behind on security patches to preserve an extension is a trade very few organizations would approve if it were written down as a proposal.
The forks are where this actually bites
Here is the part that is barely being covered. Several Chromium-based browsers still support Manifest V2 extensions after Chrome stopped. They have largely been letting users install those extensions from the Chrome Web Store, because building and maintaining a separate extension catalog is expensive.
Brave has been the most explicit about its position. Its statement on Manifest V3 commits to continuing "to support some privacy-relevant MV2 extensions, specifically AdGuard, NoScript, uBlock Origin, and uMatrix," while being candid about the limits of that promise: the feature is "best-effort" and Brave "might have to modify support based on either Google’s plans or what extension authors ultimately decide to do." Brave also makes the argument that its built-in Shields, which "block ads and trackers by default" with no extension required, are the more durable answer regardless.
August 31 is exactly the kind of Google plan that clause was written for. Continuing to support an extension format is one problem. Continuing to distribute extensions in that format once the shared catalog is gone is a different and harder one. Vivaldi’s community has been discussing the same question, without an official statement resolving it at the time of writing.
If you moved to a fork specifically to keep a Manifest V2 content blocker, this is the date to check your assumptions against your browser vendor’s actual commitments rather than against a forum thread. The same instinct applies to browser choice generally, which we covered in agentic browser security.
What Manifest V3 does and does not permit
The substantive objection to Manifest V3 was always about content blocking, and it is worth stating precisely rather than as a slogan. Manifest V3 replaced the blocking webRequest API, which let an extension inspect and decide on each request in its own code, with declarativeNetRequest, where the extension registers rules and Chrome enforces them.
The rule budgets are documented and have been raised over time. Chrome’s declarativeNetRequest reference currently documents up to 100 static rulesets with 50 enabled at once, collectively "guaranteed at least 30,000 rules," 30,000 dynamic rules, 5,000 session rules, and a cap of 1,000 regular expression rules per type.
For the majority of blocking, that is sufficient, and modern filter lists fit. What it does not permit is an extension making a novel decision per request at runtime, which is where a class of anti-tracking and anti-fingerprinting behavior lived. Whether that class matters to you is a real question with a real answer that depends on your threat model, and it is not the same question as whether ads get blocked.
What is worth doing before August 31
Four things, in rough order of urgency.
Mirror anything you still need. If you maintain or depend on a Manifest V2 extension that is not published anywhere but the Chrome Web Store, download the artifact this week. After the removal there is no supported path back to it.
Audit for pinned browsers. Search your fleet for anything held at Chrome 138 or earlier. Decide explicitly whether the extension it preserves is worth thirteen months of missed security updates, and write the decision down either way.
Confirm your fork’s plan in writing. If you rely on a Chromium fork for Manifest V2 support, find the vendor’s current statement rather than assuming continuity. Brave’s is public and carries explicit conditions.
Check what your blocker actually became. Several well-known blockers now ship a Manifest V3 build alongside the original, with different capabilities under the same familiar name. Verifying which one you are running takes a minute and settles most of the anxiety in this space.
The precedent worth noticing
Set aside extensions for a moment. What Google demonstrated over four years is that a platform vendor can retire an entire third-party execution model on a published schedule, absorb sustained public objection, and finish roughly on time. The parts that made it work were the long runway, the staged defaults, and the enterprise policy that gave the loudest constituency somewhere to go for three years.
That template is now available to every other platform holder, and browser extensions are not the only place it applies. Anyone whose product depends on a permission or an API that a larger vendor grants is looking at a worked example of how that permission gets withdrawn. The relevant lesson from the last four years is not that Manifest V3 is good or bad. It is that a four-year deprecation notice is a real notice, and the constituency that treated 2022 as an opening negotiating position rather than a schedule got the schedule anyway.
The same dynamic is running right now in how sites control automated access, which we covered in auditing your site for AI crawler access, and in how browser vendors decide what an agent may do on a page, covered in retiring the ChatGPT Atlas browser.
Frequently Asked Questions
What is the exact manifest v2 removal date?
August 31, 2026. On that date Google removes all remaining Manifest V2 extensions from the Chrome Web Store, per its published Manifest V2 support timeline.
Will my Manifest V2 extensions stop working on August 31?
In Chrome they already stopped. Chrome 138, released July 24, 2025, disabled Manifest V2 extensions for all users with no option to re-enable them. The August 31 date removes the store listings, not the code on machines still running Chrome 138 or earlier.
Can I reinstall a Manifest V2 extension after the removal?
Not from the Chrome Web Store. Google’s timeline states that removed extensions cannot be reinstalled from the store. If you need one, obtain the artifact before August 31.
Does the enterprise policy still let managed fleets run Manifest V2?
No. The `ExtensionManifestV2Availability` policy covered enterprise users until June 2025, Chrome 138 was the last version to honor it, and Chrome 139 removed support for all users.
What happens to Brave, Vivaldi, and other Chromium forks?
Forks that still support the format keep supporting it, but the shared catalog they have been sourcing from disappears. Brave has publicly committed to supporting several privacy extensions on a best-effort basis, with an explicit caveat that support may change based on Google’s plans or on what extension authors decide.
Can Manifest V3 extensions still block ads?
Yes. Blocking now happens through declarative rules that Chrome enforces rather than through per-request extension code. Chrome documents at least 30,000 static rules, 30,000 dynamic rules, and 5,000 session rules, which accommodates mainstream filter lists.
So what did Manifest V3 actually take away?
The ability for an extension to run its own logic against each individual network request as it happens. That mattered for a class of adaptive anti-tracking and anti-fingerprinting techniques rather than for ordinary list-based blocking.
Is there anything to do if I only use Chrome and default settings?
Almost certainly not. Your Manifest V2 extensions were disabled thirteen months ago and whatever you are running today is already Manifest V3. The date is administrative for you.
