Chrome Deletes the Last Manifest V2 Extensions on August 31: What Actually Happens

The countdown timers are back. Some site put one at the top of an article this week: days, hours, and minutes ticking down to August 31, 2026, the morning "Chrome kills your extensions." The all-caps version adds an exclamation point.

I'll save you the arithmetic. The extensions that August 31 supposedly kills stopped running last summer, and if you're reading this in a Chrome that works, none of yours are on the list. The dramatic part of this story already happened, quietly, more than a year ago. What's left is a database cleanup at the Chrome Web Store.

Two things, then. First, the boring reassurance, with exact dates, because a wrong date is the whole reason people are scared. Then the part worth your time: why Google spent four years dragging every extension developer through this migration, and whether the people who lost their favorite ad blocker have a real complaint. They partly do, and I'll say where.

The dramatic part already happened

Manifest V2 is the format that described Chrome extensions for over a decade. It launched in 2012. Its replacement, Manifest V3, reached stable Chrome on January 19, 2021, and then Google spent years slowly closing every door that let the old format keep running. The timeline matters, because each step removed a different escape hatch, and the one that actually turned MV2 off is well behind us.

Here's the ratchet, most of it straight from Chrome's own deprecation timeline, with one later step I'll flag as coming from elsewhere:

June 3, 2024 was the first warning shot, but only developers and early-adopters saw it. Warning banners appeared on chrome://extensions for MV2 extensions on Chrome's Beta, Dev, and Canary channels, and those extensions lost their "Featured" badge in the store. If you were on stable Chrome, which is almost everyone, you saw nothing yet. Your turn came later, in the run-up to October. (Getting this one right matters: a post scolding the press for fumbling the timeline had better not fumble the first date on it.)

October 9, 2024 was the first thing that actually bit. Chrome began disabling MV2 extensions on the stable channel, rolling it out gradually. If yours got switched off, you could still flip it back on, for now.

March 31, 2025 made "off" the default everywhere. MV2 extensions were disabled by default on every channel, though users could still re-enable them by hand, and enterprises got a reprieve: an admin policy called ExtensionManifestV2Availability kept MV2 alive on managed machines, extended through June 2025.

July 24, 2025 (Chrome 138) is the date that matters. As of that date, MV2 was disabled for all users on all channels, and the manual re-enable toggle was gone. You could no longer turn your old extensions back on. Chrome 138 was also the last version of Chrome that could run an MV2 extension at all, and only then through that enterprise policy.

Chrome 139, the very next release, deleted the enterprise policy too. That closed the final door. From Chrome 139 onward, there is no supported way — not a toggle, not a flag, not an admin override — to run a Manifest V2 extension on Chrome. That change hit every Chrome 139 user at once.

Chrome 151, which reached stable around July 28, 2026, swept up the last bit of dust: it removed the final developer flag (#extension-manifest-v2-deprecation-unsupported) that could coax MV2 back to life on a dev build. This is the one step here that isn't in Google's official timeline (that document stops at Chrome 139), so I'm taking it from the tech press that tracked the flag's removal. Treat it as well-corroborated rather than gospel; either way it changes nothing for a normal user, who lost MV2 back at 138.

Read that list again and notice where the real switch is. Everything load-bearing happened between October 2024 and Chrome 139 in mid-2025. By the time you're reading this, MV2 has been dead on ordinary Chrome for a full year.

What August 31 actually changes

So what happens on the 31st? The Chrome Web Store removes the remaining Manifest V2 listings. That's the whole event. Google's timeline puts it plainly: the leftover MV2 extensions come off the store, and any that are still 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."

Two consequences fall out of that, and neither is the one the headlines promise.

The first is that you can't get those extensions anymore. No install, no reinstall, no update. If a listing was limping along collecting downloads from stragglers on old builds, that stops. The store page 404s.

The second is subtler and worth sitting with. Nothing in your running browser changes on August 31, because on current Chrome the affected extensions already don't run. The store removal isn't a kill switch; the kill happened in Chrome 138 and 139. This is Google tidying up the shelf after the milk already went off.

The honest version of the August 31 story is unglamorous: a listing gets deleted, a few people on old or unusual browsers lose the ability to reinstall something that was already broken for everyone else, and the rest of us don't notice. That doesn't make a good countdown timer.

How to check whether any of this touches you

You almost don't need to. The practical test is the one I keep repeating: if your extensions work, they're V3, and you're done. MV2 can't run on your Chrome, so "it runs" is proof.

If you want to look anyway, open chrome://extensions. Chrome flags the dead ones for you. An MV2 leftover shows up greyed out, toggled off, usually with a note that it's no longer supported and a little trash-can prompt to remove it. Everything else, every extension that's enabled and doing its job, is Manifest V3. There's no hidden MV2 quietly working; "quietly working" is exactly the thing Chrome 138 made impossible.

If you're the kind of person who wants to see it in the file, flip on Developer mode in the top-right of chrome://extensions, click an extension's Details, and you can inspect its folder. The manifest tells you outright:

{
  "manifest_version": 3,
  "name": "Some Extension",
  "version": "1.4.2"
}

A 3 there is the whole answer. A 2 would mean an extension Chrome is no longer willing to run. In practice you'll only ever find 2 on something already disabled.

Why Google actually forced this

Now the part that makes this a how-it-works post instead of a news blurb. Manifest V3 wasn't cosmetic. Google rebuilt three specific mechanisms, and each one traded capability for a property Google wanted. I think two of the three trades are clearly defensible and one is genuinely contested. Let me take them in order and be fair to both sides, because the internet has largely picked a team on this and stopped reading.

The code can't change after Google looks at it

Under Manifest V2, an extension could fetch code from a server at runtime and execute it. A background page could pull down a script and eval it, or inject a remote <script> tag, and suddenly be running logic that was never in the package Google reviewed:

// Manifest V2 background page — the pattern MV3 bans outright
(async () => {
  const res = await fetch("https://vendor.example.com/latest-logic.js");
  // This runs code Google's reviewers never saw. It can change any time
  // the server changes, with no new review and no user prompt.
  eval(await res.text());
})();

Manifest V3 forbids remotely-hosted code. All executable logic has to ship inside the extension package that went through review. Manifest V2 already blocked eval and remote scripts by default, but it let a developer loosen the content security policy to allow them. V3 removes that escape valve: there is no supported way to weaken the policy back into running code you fetched at runtime. Chrome's migration docs are blunt that remotely-hosted code isn't allowed: an extension can reference and use only the JavaScript files present in its own bundle.

Frame it from the user's side and this one is hard to argue with. Under MV2, the thing Google reviewed and the thing running in your browser could be two different programs. An extension could pass review as a tidy little utility, then phone home a week later and become a keylogger, and the review that was supposed to protect you covered a version that no longer existed. Banning remote code means the reviewed artifact and the running artifact are the same artifact. That's a real security win, and it's the change I'd defend without flinching.

The cost is narrow but real: legitimate patterns that shipped logic remotely — some A/B testing frameworks, remote feature flags that carried behavior rather than just data, quick hot-fixes without a store round-trip — all broke and had to be rebuilt inside the package. Annoying for developers. Good for users. I'll take the trade.

The browser blocks requests now, not the extension

This is the one people are actually angry about, and they're not wrong to be.

Manifest V2 gave extensions a blocking version of the webRequest API. It let an extension register a listener that Chrome would call for every single network request the browser made, hand it the details, and wait for the extension's own JavaScript to decide, at that moment, whether to allow it, block it, or rewrite it:

// Manifest V2 background page — blocking webRequest
chrome.webRequest.onBeforeRequest.addListener(
  (details) => {
    // Arbitrary code runs for every request and decides, live, what to do.
    if (looksLikeAnAd(details.url)) return { cancel: true };
  },
  { urls: ["<all_urls>"] },
  ["blocking"] // <-- this mode is what MV3 removed
);

That is enormous power. It's also enormous visibility: to make that decision, the extension gets to see every URL you request, in code it fully controls. That's exactly what made blocking webRequest the foundation of serious content blockers, and exactly what made Google nervous about it.

Manifest V3 replaces it with declarativeNetRequest. Instead of running your code on every request, the extension declares its rules ahead of time, and the browser's own network stack enforces them:

// rules.json — declarativeNetRequest static rules (Manifest V3)
[
  {
    "id": 1,
    "priority": 1,
    "action": { "type": "block" },
    "condition": {
      "urlFilter": "||ads.example.com^",
      "resourceTypes": ["script", "image", "xmlhttprequest"]
    }
  }
]

// manifest.json — wiring that ruleset in
{
  "manifest_version": 3,
  "permissions": ["declarativeNetRequest"],
  "declarative_net_request": {
    "rule_resources": [
      { "id": "ruleset_1", "enabled": true, "path": "rules.json" }
    ]
  }
}

The difference is the whole argument. With declarativeNetRequest, the extension never sees your traffic. It hands Chrome a rulebook, Chrome does the blocking, and the extension is out of the loop. Google's case is privacy plus performance: your ad blocker can no longer read your entire browsing history request-by-request, and there's no extension JavaScript sitting in the hot path of every network call. Both of those are true, and for the median extension they're a clean upgrade.

The cost is that declarative rules can't express everything code could. declarativeNetRequest caps how many rules you can ship: a guaranteed minimum of 30,000 static rules, up to 30,000 dynamic ones, and 5,000 session rules. Google has raised those budgets more than once as the complaints came in. The safe dynamic-rule limit jumped from 5,000 to 30,000 in Chrome 121. But the count was never the real ceiling. Declarative rules can't make decisions that depend on what a response actually contains, or chain logic the way real code can. Dynamic, situational, "look at this and then decide" blocking was the entire point of the advanced tools, and the rulebook model can't reproduce all of it. This is what kneecapped the heavy-duty content blockers, and the backlash was earned.

Here's the honest steelman for the people who are furious, because they deserve a fair hearing and not a shrug. Grant Google every word of the privacy argument. It's still true that declarativeNetRequest is strictly less expressive than blocking webRequest, and no amount of good intent closes that gap. And there's an uncomfortable optics problem sitting underneath: the company telling you your ad blocker has to get weaker, for your own privacy, is the company that sells the ads. You can believe the privacy benefit is real and believe the same benefit could have been reached with less collateral damage: a stricter permission, an audit path for trusted blockers, a narrower API instead of a blunter one. I don't think Google acted in bad faith here. I do think "trust us, it's for your privacy" is a big ask from the ad company, and the critics who wanted the win without the amputation have a point.

The background page stopped being always-on

The third change is the one developers grumbled about most and users noticed least. Manifest V2 extensions had a persistent background page: a hidden page that loaded when the extension started and stayed resident for the whole browser session, holding whatever state it liked in plain variables.

Manifest V3 replaced it with a service worker. A service worker is event-driven and ephemeral: Chrome spins it up to handle an event, lets it go idle, and terminates it after roughly 30 seconds of inactivity. Google's argument is memory and performance: an extension you're not actively using shouldn't be squatting on a live process and a chunk of RAM just in case. On a machine with forty tabs and a dozen extensions, that adds up, and event-driven workers that unload when idle are the right default.

The friction is that "your background context can be killed at any moment" forces a real rewrite. Any state you kept in a global variable evaporates when the worker unloads. Listeners have to be registered synchronously at the top level or the event that would have woken the worker gets missed. setTimeout for anything longer than the idle window is a trap, because the timer dies with the worker; you reach for chrome.alarms instead. None of it is exotic, but all of it is different, and a decade of MV2 code and tutorials assumed the opposite. I wrote a whole separate post on why MV3 service workers keep dying and how to build around them if you want the gory lifecycle details.

I ship BumbleTap on this model, so take my verdict for what it's worth: I made my peace with it. The rewrite is real work the first time through, and after that it's just how the platform is. It is what it is, and once you stop expecting a background page that never dies, the ephemeral worker mostly stays out of your way. What's telling is that after all of it, the one place this migration actually landed on me wasn't a line of my own code. It was losing the real uBlock Origin, which is the part everyone actually showed up for.

So is uBlock Origin gone?

This is the question most people are actually typing into a search box, so here's the direct answer: the uBlock Origin you're thinking of — Raymond Hill's original, the one built on blocking webRequest — no longer runs on Chrome. It went dark with every other MV2 extension in mid-2025. On Chrome, that specific thing is over.

But "gone" oversells it. Hill (who goes by gorhill) built a Manifest V3 version called uBlock Origin Lite, or uBOL. It uses declarativeNetRequest and pre-compiles filter lists into static rulesets at build time. For most people, on most sites, it blocks most ads, and it does it with a smaller footprint than the original.

It is also, by design, less capable, and gorhill has never pretended otherwise. Because uBOL leans on static rules instead of live code, it can't do the dynamic, per-site, "watch what the page does and react" filtering the full version was known for. Its cosmetic filtering (the part that hides leftover empty ad boxes and page furniture) is more limited, and it can't adapt to a new anti-adblock trick until gorhill ships a fresh ruleset through the store's review queue and you update. For a casual user, uBOL is fine. For someone who ran the full uBlock Origin because they needed the advanced knobs, "fine" is a demotion, and calling uBOL a drop-in replacement would be dishonest.

The full uBlock Origin isn't extinct, though. It just doesn't live on Chrome anymore. Firefox kept the blocking webRequest API, so the complete, unabridged uBlock Origin still runs there today. Brave took a different route entirely: its ad and tracker blocking is built natively into the browser rather than shipped as an extension, so Manifest V3's rules for extensions simply don't apply to it: requests get filtered deep in Brave's own network stack by a Rust engine, untouched by any of this. AdGuard, similarly, offers a standalone application that filters outside the extension sandbox as well as an MV3 extension.

For the record, here's where I landed, since I've spent this section describing what everyone else does. I drifted to Edge for daily browsing. It's Chromium underneath, but it hasn't pulled the plug on the full uBlock Origin the way Chrome did, so for now the unabridged thing still runs there, and I've quietly come to like Edge anyway. In Chrome I keep uBO Lite and mostly shrug; it catches what I care about. That's the real-world shape of it: the people who needed the full tool keep a second browser around for it, and everyone else takes the lite version and moves on. The catch is that "for now": Microsoft hasn't committed to an Edge cutoff, so it's a reprieve, not a promise.

Where this leaves you

For you, as someone who just wants their browser to work: basically nothing. Your extensions are V3 or they wouldn't be running. August 31 deletes some store listings you weren't visiting. The internet's countdown timers are counting down to a database DELETE.

The one genuinely practical thing to do is future-proofing, not firefighting. If there's a Manifest V2 extension still clinging on somewhere in your world (an old machine your team never updated, a locked-down work laptop, a Chromium fork with its own rules), understand that once the listing is gone, that extension can't be reinstalled or moved to a new device. So if you depend on one, go find its V3 successor now, while you can still search the store for it. After August 31, the trail goes cold.

On the other browsers: Edge, Brave, Opera, and the rest are all Chromium underneath, so they all inherit the Manifest V3 platform and will land in the same place eventually. But they set their own clocks. Brave, as above, blocks natively and mostly sidesteps the extension-API drama. Microsoft has said it will decide Edge's Manifest V2 timeline independently rather than mirroring Chrome's dates. Its published migration schedule still lists Edge's MV2 cutoff as undecided, and MV2 keeps working there via enterprise policy at least as long as it does upstream in Chromium. The safe rule: Chrome's August 31 date is a Chrome date. Don't assume it governs whatever else you run.

One aside, since it's fair to disclose where I'm standing. The extension I build, BumbleTap, is Manifest V3 and doesn't fetch code from a server to run: everything it executes ships inside the reviewed package. So for me this migration was the water, not a wave: it's just the shape the platform is now. I'm not neutral about MV3, but I'm also not its victim, and I've tried to keep both of those true above.

The real story here was never August 31. It's the four-year trade Google made: some concrete user power, mostly in the hands of people running serious content blockers, exchanged for a platform where a reviewed extension can't secretly rewrite itself, can't read all your traffic, and can't idle in the background eating RAM. Two of those three are wins I'd defend to anyone. The third one cost real people a real tool, and Google's cleanest privacy argument for it comes, awkwardly, from the largest ad company on earth. Hold both. The countdown timers can't.

Caveats

• Every date and version above is Chrome's published deprecation timeline as of mid-2026. Version numbers and cutoffs have moved more than once across this rollout; if you're reading this much later, check the current Manifest V2 deprecation timeline rather than trusting a snapshot.
• Edge, Brave, Opera, and other Chromium browsers inherit Manifest V3 but run their own schedules. Nothing here about Chrome's dates should be read as a promise about a non-Google browser. Confirm against that browser's own announcements.
• declarativeNetRequest's rule limits are specific numbers, and Chrome has raised them more than once: the safe dynamic-rule budget jumped from 5,000 to 30,000 in Chrome 121. The figures above are current as of mid-2026; check the API reference before you design around a cap.
• uBlock Origin Lite is under active development, and its capability gap versus the original narrows as gorhill and the DNR API both improve. Treat any "uBOL can't do X" claim, including mine, as a thing to re-test rather than a fixed law.
• This describes Chrome's extension platform. Chrome on iOS runs WebKit and a different extension story entirely, and Chrome on Android doesn't run this class of extension at all.