If an ad blocker, tracker blocker, or YouTube utility you relied on quietly lost features or disappeared since mid-2025, the cause was almost certainly Chrome's Manifest V3, the largest structural rewrite of Chrome's extension rules in years. In most cases it was not developer neglect. Manifest V3 did not simply swap one API for another; it restricted which capabilities extensions are allowed to use, and some tools could not be rebuilt faithfully inside the new rules no matter how motivated their developers were.
This article covers the Manifest V3 changes explained in plain terms: the shutdown calendar that ended Manifest V2, the replacement of blocking webRequest with declarativeNetRequest, the service workers that replaced persistent background pages, the store review friction that slowed every migration, and the different path Firefox took. It ends with a six-question checklist you can apply to any extension you depend on, so you can judge whether it will survive before it breaks.
The shutdown calendar: July 2025 to August 2026
Google's deprecation timeline is effectively complete for ordinary users. On July 24, 2025, Chrome 138 disabled Manifest V2 extensions for everyone, and Google's documentation states the consequence plainly: "With Chrome 138 all users on all channels of Chrome have now Manifest V2 extensions disabled. Users can no longer turn them back on." Chrome 139 then removed the ExtensionManifestV2Availability enterprise policy, closing the last official escape hatch that organizations had used to keep MV2 extensions running.
Manifest V2 went dark for regular users in July 2025; the last copies leave the Chrome Web Store on August 31, 2026.
One milestone remains. On August 31, 2026, all remaining MV2 extensions will be removed from the Chrome Web Store. Already-installed copies keep working locally, but they stop receiving updates, and once the store listing is gone the extension cannot be reinstalled.
For most people, the deadline has already passed. The practical question now is not whether Manifest V2 is going away; it is which surviving extensions were rebuilt properly for MV3 and which were patched just enough to keep the store listing alive.
The end of blocking webRequest
Under Manifest V2, an extension could observe every network request the browser made and decide in JavaScript whether to block, redirect, or modify it. Classic ad blockers, anti-tracking tools, and sponsor-skippers all worked this way: inspect each request in code, make a decision on the spot.
Under MV3 the browser itself evaluates shipped rules instead of running extension code on each request.
Manifest V3 removes that runtime interception for blocking purposes and replaces it with declarativeNetRequest: the extension ships rules, and Chrome's own engine evaluates them without running extension code per request. Google frames the change as faster and more privacy-preserving, since rule evaluation happens natively and extension code no longer sits in the middle of your traffic. The cost is just as real. A declarativeNetRequest-based extension cannot make per-request decisions in code, so blockers whose logic depended on inspecting traffic and improvising a response had to be rearchitected or accept reduced behavior.
The casualties were overwhelmingly dynamic request-blockers. One exception survives: policy-installed, enterprise-managed extensions retain the webRequestBlocking permission under MV3, which is why managed installs can still run intercepting tools that consumer installs cannot.
The rule-count math: where rebuilt filters hit the ceiling
Manifest V3 browser extensions that filter content negotiate a fixed budget instead of free-form code. Chrome maintains a global shared pool of 300,000 static rules across all installed extensions and guarantees each extension an allowance of 30,000, per the extension documentation. For scale, EasyList contains roughly 35,000 network rules, so a single major list fits; stacked lists and multiple filtering extensions compete for the shared pool. Extensions can declare up to 100 static rulesets, of which only 50 can be enabled at once.
Dynamically added rules are tighter still: 30,000 per extension in Chrome, with a stricter cap of 5,000 on rules classed as unsafe, such as redirects, counted within the 30,000.
These numbers explain why some rebuilt blockers feel different rather than broken. Adaptive, code-driven filtering logic cannot be transcribed verbatim into static rules. The developer decides which rules fit the budget, and users who run several filtering extensions at once split a single shared pool across all of them.
Service workers: the silent breaker
The Chrome extension Manifest V3 impact did not stop at blockers. MV3 replaced persistent background pages with service workers. An MV2 background page lived as long as the browser ran, so an extension could hold timers, counters, and cached data in memory indefinitely. An MV3 service worker idles out and can be terminated between events, then cold-starts the next time something wakes it.
A killed service worker raises no error; in-memory timers simply never fire again.
The classic casualty is setInterval. In-memory timers simply never fire after the worker is killed, and nothing logs an error. That is why this change is the silent breaker: extensions do not crash, they just quietly stop remembering things. A feed checker meant to poll every hour stops polling. A utility that tracked state in a variable loses it between wakes.
The compliant pattern is well defined: use chrome.alarms for anything scheduled, and persist every piece of state to Chrome extension storage between wakes so the next cold start can rebuild it. A tool that periodically polls YouTube feeds, for example, must keep its lists, watched flags, and playback queues in storage rather than memory. That is the same local-first approach required when building a fully client-side Chrome extension with no backend. For developers it doubles as a quick credibility test: code full of setInterval calls and in-memory state is not MV3-ready, whatever the store listing claims.
How Firefox diverges
Firefox adopted the MV3 manifest format but kept the capabilities Chrome removed, which is why it became the refuge for privacy-extension users. Blocking webRequest still works there, so extensions can keep inspecting each request and deciding in code instead of pre-declaring static rules, and code-driven privacy tools keep their full behavior. Firefox also retains non-persistent background pages for now.
The limits still differ in both directions. Firefox caps dynamic declarativeNetRequest rules at 5,000 versus Chrome's 30,000, per MDN's compatibility documentation. A developer porting a filtering extension between the two browsers therefore needs browser_specific_settings in the manifest, has to reconcile permission differences, and must manage rule sets with per-browser caps in mind.
The broader takeaway: MV3 is not one spec. Chrome enforces the strictest interpretation, so an extension that works in Firefox is not guaranteed to behave identically in Chrome. When you judge a tool's MV3 readiness, the browser it targets matters as much as its manifest version.
Why a subscription manager like Yougroup survives by design
Architecture choices predict extension survival better than release notes do. Yougroup, Thoughtbubble's open-source YouTube subscription manager, is a useful worked example because every choice that matters here is visible in its design.
It never uses blocking webRequest and never intercepts traffic, so the entire declarativeNetRequest migration simply does not apply to it. It reads public YouTube RSS feeds for uploads instead of modifying YouTube's pages or network traffic, an approach with its own tradeoffs versus RSS readers and web apps; no YouTube Data API key is required for core functionality, and an optional key only adds richer details such as duration and view counts. It also holds no persistent background state: lists, watched flags, and playback queues live entirely in Chrome extension storage, which is exactly the storage-backed pattern ephemeral service workers require.
There is no Yougroup account, hosted backend, server-side sync, or product analytics. That removes the remote kill switch a platform change or a company shutdown could trip. The MV2 deadline forced no rewrite, because the tool never depended on the capabilities MV3 removed.
Store review friction and remote-code bans
Two policy changes arrived alongside MV3 and squeezed extensions that technically survived it: Chrome Web Store review cycles lengthened, and MV3 bans remote code, meaning an extension can no longer fetch scripts at runtime and execute them.
The remote-code ban is a genuine security improvement, since runtime-delivered scripts can deliver anything, including malware. But it punishes loosely architected tools that leaned on runtime-delivered code to change behavior without shipping a new version. Combined with slower reviews, the practical effect is that a closed-source utility can lag months behind a fix, because every change must pass review before it reaches users.
Open-source extensions have a fallback that closed-source tools lack: anyone can clone the code, build it, and load the unpacked extension in Chrome 114 or later, independent of the store and with full visibility into what runs. Transparency here is not philosophy; it is an operational fallback.
Will my extension still work? A six-question checklist
Apply these to any extension you depend on. Questions one through three detect hard MV3 limits. Questions four through six detect sustainability risks. Both failure modes look identical from the outside, an extension that quietly stops working, but they demand different responses.
- Does it dynamically block or rewrite network requests? If yes, it must fit inside declarativeNetRequest's rule caps, and it can no longer make per-request decisions in code.
- Does it keep state only in memory between events? If yes, it breaks when the service worker idles out. The real fix is chrome.alarms plus persistent storage, not a patch.
- Does it load remote code or fetch scripts at runtime? If yes, it is banned outright under MV3, not merely restricted.
- Does it depend on a hosted backend that can be shut off? That risk is independent of MV3; the extension dies with the server.
- Is it closed-source with a single maintainer? Another sustainability risk, with no community fallback if the maintainer walks away.
- Has it received updates since the MV2 shutdown deadline? Silence after mid-2025 is a dead-extension signal, even if the store listing still works.
Failing questions one through three means the extension is fighting MV3's limits. Failing four through six means it is fighting time.
What to do when an extension will not survive
The right alternative depends on which failure mode you found.
When a favorite tool cannot be rebuilt inside the new rules, the practical move is a different browser or a differently built tool.
If the extension hits MV3 limits, look for a declarativeNetRequest-rebuilt version and check whether it fits your setup. The static rule pool is shared across all filtering extensions, so two rebuilt blockers on one browser split a single budget. If no faithful rebuild exists, Firefox is the browser where blocking webRequest survives for regular users, which is why many privacy-extension users moved there.
If the extension fails on sustainability, prefer tools whose survival does not depend on one maintainer's attention or one company's servers: open-source extensions with active maintenance and local-first storage. You can see where your data lives, and you keep the option of building and loading the code yourself if the store version ever falls behind.
The larger lesson is that architecture predicts survival. When you add an extension, ask where its state lives, whether it intercepts traffic, and what happens if its developer disappears. Then run the six questions above against the extensions you rely on this week, while the August 2026 store purge is still a deadline rather than a memory.