By ByteBot
On August 31, 2026, Google deleted every remaining Manifest V2 extension from the Chrome Web Store — permanently. uBlock Origin, AdGuard Ad Blocker, hundreds of developer tools: wiped from the catalogue. If you maintain a Chrome extension still running on MV2, you are now locked out of 3+ billion users. Not deprecated. Gone.
The Purge Was the Last Step, Not the First
Here is where most coverage gets this wrong: MV2 extensions stopped running in Chrome 138, released July 2025. That was the actual cutoff — over a year ago. What happened on August 31, 2026 is the Store purge: Google removed all remaining MV2 listings, killing update distribution, new installs, and Store visibility for anything still on MV2.
The distinction matters. If your users already have the extension installed, they are not suddenly cut off. But if they remove it and try to reinstall, they cannot. And you cannot push a bug fix or security patch through the Web Store anymore. For practical purposes, an MV2 extension is now abandonware on Chrome.
What the API Change Actually Costs You
The architectural shift from MV2 to MV3 is not cosmetic. In MV2, the webRequest API let your extension intercept every network request in real-time JavaScript — inspect it, block it, redirect it, modify headers, all programmatically. That is what made ad blockers, privacy tools, and developer utilities genuinely powerful.
MV3 replaces this with declarativeNetRequest (DNR): you submit a JSON rulebook ahead of time, and Chrome’s native engine applies the rules without ever running your extension code per request. Faster? Yes. More private for users? Arguably. But you lose real-time programmatic inspection entirely. There is no workaround — it is a deliberate design choice by Google, not a technical limitation. Google explicitly wanted to reduce the power of extensions over network traffic.
The rule cap that initially made this untenable — 30,000 static rules — has been raised to 330,000. For most filter-list use cases, that is now sufficient. The remaining pain point is update latency: new filter rules ship inside the extension package and go through Store review, meaning a 1-to-5-day lag before new blocking rules reach users. MV2 could update rule lists in real time.
The Service Worker Rewrite
The other major migration pain is the background context. MV2 extensions used persistent background pages — always running, with DOM access, localStorage, and XMLHttpRequest available. MV3 uses service workers: event-driven, ephemeral (Chrome terminates them after roughly 30 seconds of inactivity), and without DOM access.
The manifest change is straightforward:
// MV2
"background": { "scripts": ["background.js"], "persistent": false }
// MV3
"background": { "service_worker": "service-worker.js", "type": "module" }What breaks your code: anything relying on in-memory state across requests. Service workers have no persistent memory between invocations. Replace localStorage with chrome.storage, replace XMLHttpRequest with fetch, and rebuild your state management logic around the chrome.storage API. Idle termination is the number one gotcha — developers consistently undertest this and hit production bugs when a service worker wakes up with a blank state.
The Ecosystem Split Changes Your Strategy
Google’s move has fractured the browser extension market. Firefox is explicitly maintaining MV2 support in parallel with MV3, indefinitely. Mozilla has been direct: uBlock Origin is not going anywhere on Firefox. Brave is going further — it is self-hosting uBlock Origin, AdGuard, uMatrix, and NoScript on its own servers so Brave users retain full MV2 access.
For extension developers, this creates a real strategic question. If your extension relies on dynamic request inspection — the kind that declarativeNetRequest cannot replicate — Chrome is no longer your platform. Raymond Hill, the creator of uBlock Origin, has been explicit: a functional MV3 port of the full uBlock Origin is not possible. That is not defeatism; it is an accurate reading of what DNR allows.
If you maintain a content-blocking or advanced privacy extension, Firefox and Brave are now the viable targets. The combined user base is smaller than Chrome’s 3+ billion, but it is the only base where your extension can function as designed.
What to Do Right Now
For most extension developers — those not building content blockers — MV3 migration is straightforward and overdue. Check your manifest.json: if manifest_version is 2, you need to migrate or your Chrome distribution is finished. The official Chrome MV2 deprecation timeline and the service worker migration guide are the authoritative starting points.
For those with content-blocking or deep network-inspection use cases, AdGuard’s write-up on the removal captures the reality well: you are not migrating Chrome functionality, you are deciding which functionality to cut and which browsers to prioritize.
Either way, August 31 is not a future deadline. It already happened. If you have not acted, act now.
