Chrome Extension Manifest V3

Chrome's multi-year overhaul of its extension platform is entering its final phase in 2026. If you build browser extensions, run a business that depends on one, or just want to understand why your ad blocker suddenly behaves differently, this is the year the last exits close. Here's what actually happened, what's still happening, and what it means in practice.

What Manifest V3 is

Every Chrome extension ships a manifest.json file that declares its permissions, background scripts, and capabilities. "Manifest V3" (MV3) is the third version of that specification, and it replaces Manifest V2 (MV2), which had been the standard since 2012. Google first announced the shift in 2019 and began enforcing it in earnest starting in 2023, with the transition now reaching its conclusion.

The stated goals were privacy, security, and performance. In practice, MV3 rewrites how extensions are allowed to run code, intercept network requests, and handle background processes — and those changes have real consequences for what extensions can and cannot do.

The four changes that matter

1. Service workers replace persistent background pages. Under MV2, an extension could keep a background page open indefinitely, consuming memory and CPU even when doing nothing. MV3 requires extensions to use service workers instead, which spin up only when needed and terminate after a period of inactivity. This is a genuine performance win for the browser as a whole, but it also means extensions can no longer rely on long-running in-memory state — they have to persist data explicitly and re-initialize more often.

2. declarativeNetRequest replaces the blocking webRequest API. This is the change with the most visible fallout. Under MV2, extensions could inspect and modify every network request in real time via the webRequest API — the mechanism that powered ad blockers, privacy tools, and request-rewriting utilities. MV3 replaces this with declarativeNetRequest, where the extension registers a static set of rules up front and the browser applies them, rather than handing raw request data to extension code. As of 2026, Chrome caps this at roughly 30,000 static rules per extension — far short of the 300,000+ rules a fully configured uBlock Origin used to run under MV2.

3. Remote code execution is banned. MV3 extensions can only execute JavaScript that ships inside the reviewed extension package. They can no longer fetch and eval() remote scripts at runtime. This closes a real security hole — it was a known vector for extensions to change behavior post-review — but it also breaks legitimate update patterns some extensions relied on.

4. Host permissions are tightened and more visible to users. Extensions must declare which sites they can access, and Chrome surfaces this more prominently, giving users finer-grained control to grant or revoke site access per extension rather than all-or-nothing.

The 2026 timeline

The deprecation of Manifest V2 has moved in stages, and it's worth being precise about dates because a lot of outdated advice is still circulating:

• June 2024 — Warning banners started appearing on Chrome Beta, Dev, and Canary for MV2 extensions still listed in the Web Store.
• October 2024 — Chrome Stable began disabling MV2 extensions for a subset of users, who could still manually re-enable them.
• March 2025 — MV2 extensions became disabled by default for all users on all Chrome channels, though re-enabling was still temporarily possible.
• July 2025 (Chrome 138) — MV2 support was removed for all users on all channels. Users can no longer re-enable MV2 extensions at all in stable Chrome. Enterprise policy exemptions, which had let managed organizations keep MV2 extensions running past the consumer deadline, are also being phased out starting with Chrome 139.
• August 31, 2026 — All remaining Manifest V2 extensions are removed from the Chrome Web Store entirely. Extensions already installed on Chrome 138 or earlier can continue to run, but they can no longer receive updates and cannot be reinstalled once removed.

In short: if your business or workflow still depends on an MV2-only extension, this is the year it stops being viable — not because Google is flipping a switch on a single day, but because the last supported install paths are closing for good.

The ad blocker problem, explained

The most visible casualty of this transition has been content and ad blockers, and uBlock Origin is the case study everyone points to. Its developer, Raymond Hill, built a stripped-down MV3-compliant version called uBlock Origin Lite, but has been candid that it's a materially reduced experience compared to the original. Independent testing suggests MV3-based ad blockers now catch roughly 90–95% of what MV2 blockers caught, with the gap concentrated in first-party ads, procedural cosmetic filters, randomized ad-serving URLs, and anti-adblock scripts — precisely the categories of blocking that depended on the flexible, real-time interception webRequest allowed and that the static rule-based declarativeNetRequest can't replicate.

For users who want the full blocking experience uBlock Origin used to provide in Chrome, the practical options in 2026 are switching to Firefox (which still supports the full webRequest API for extensions) or a Chromium-based browser like Brave that ships its own native blocking engine outside the extension model entirely.

What this means if you build or rely on extensions

If you maintain a Chrome extension that's still on Manifest V2, migration is no longer optional — it's a hard requirement to keep shipping updates or remain listed at all. The core migration work involves:

• Converting background pages to a service worker and restructuring any logic that assumed persistent in-memory state
• Replacing webRequest-based blocking or rewriting logic with declarativeNetRequest rule sets, which may mean redesigning features that relied on inspecting live request bodies or headers
• Removing any remote code loading and bundling all logic into the reviewed package
• Auditing and tightening host permission requests, since Chrome now surfaces these more granularly to users

If you're a business owner who depends on a specific browser extension for internal tooling — a scraper, a CRM sidebar, an internal dashboard overlay — check now whether that extension has shipped an MV3-compatible update. If it hasn't and the vendor has gone quiet, August 2026 is when it disappears from the Web Store for good, and any browser that gets updated past Chrome 138 will no longer be able to run it at all.

A broader pattern worth noting

Manifest V3 is part of a wider trend of platforms tightening what third-party code is allowed to do inside them, in the name of security and performance, even when it constrains functionality developers and users had come to rely on. It's a tradeoff web platforms revisit constantly: the same tension shows up in how websites vet third-party scripts, iframes, and embedded widgets on their own pages. Businesses embedding any third-party JavaScript — whether a chat widget, an analytics snippet, or an automation tool — are increasingly expected to be deliberate about what that script can access and how it's sandboxed, rather than granting broad, unreviewed permissions by default. It's the same underlying principle Chrome is now enforcing for browser extensions, just playing out at the level of the browser tab instead of individual websites. If you're evaluating any embedded widget for your own site, including things like an AI lead qualifier or support chat script, it's worth asking the vendor the same questions Chrome now asks of every extension: what does this code have access to, does it ship remote logic you can't audit, and what's the actual footprint of what it's allowed to touch on your page.

Why Google made this change in the first place

It's worth understanding the original motivation, because it explains why Google has held firm despite years of developer pushback. Chrome's extension platform grants enormous trust to third-party code: an extension with broad host permissions and the old webRequest API could read, modify, or redirect essentially any traffic in the browser, on any site, in real time. That power was regularly abused. Malicious or later-compromised extensions have injected ads, hijacked search results, exfiltrated form data, and swapped cryptocurrency wallet addresses in transit — all while appearing legitimate at install time and often accumulating large user bases before being caught. Because MV2 extensions could also fetch and execute remote code, a clean extension could pass Web Store review and then silently start behaving differently days or months later, once a remote payload changed. Banning remote code execution and moving from imperative, live request interception to a declarative, pre-registered rule model closes both of those doors: reviewers can audit what an extension actually does because all its logic ships in the package, and the browser — not extension code — is what ultimately touches sensitive request data. Google has framed this consistently as a security floor-raising exercise rather than a feature decision, which is also why the migration deadlines have kept moving forward despite the friction it created for ad blockers and other power-user tools.

Migration mistakes developers keep making

For teams still working through an MV2-to-MV3 port, a few failure patterns show up repeatedly in developer forums and post-mortems:

• Assuming service worker state persists like a background page's did. A service worker can be terminated by the browser after roughly 30 seconds of inactivity and restarted fresh on the next event. Code that stashed data in a module-level variable and expected it to still be there later will silently lose that state. The fix is using chrome.storage or IndexedDB for anything that needs to survive between wake-ups, not in-memory globals.
• Under-provisioning declarativeNetRequest rule budgets. Because static rules are capped and dynamic rules have their own separate limits, extensions that generate rules programmatically at scale (for example, per-domain blocking lists) need to actively manage which rules are active rather than assuming they can register everything at once.
• Leaving unsafe-eval patterns in bundled code. Because MV3 also tightens the extension's own content security policy, bundlers or third-party libraries that rely on eval() or new Function() internally — common in some older analytics or templating libraries — will break under MV3 even though the code technically shipped inside the package rather than being fetched remotely.
• Not re-testing host permission prompts. Because Chrome now asks users to grant site access more granularly, and users are more likely to decline broad "read and change all your data on all websites" prompts than they were in the MV2 era, extensions that assumed blanket access at install time are seeing real install-to-activation drop-off that needs to be designed around, not just coded around.

What comes after Manifest V3

Chrome's extensions team has continued shipping incremental capability additions on top of the MV3 baseline rather than announcing a Manifest V4, and it's reasonable to expect that pattern to continue: narrower APIs get added back in a more constrained, declarative form as real developer needs surface, rather than the platform reopening broad imperative access. For anyone building or maintaining a browser extension going into 2027, the practical takeaway is that MV3's core constraints — sandboxed, package-only code and declarative rather than live request handling — are the new baseline to design around, not a temporary hurdle to route around while waiting for Google to reverse course.

The bottom line

Manifest V3 isn't a future change anymore — it's the present reality of Chrome. Manifest V2 extensions are disabled in stable Chrome as of Chrome 138 (July 2025), and by August 31, 2026, they'll be gone from the Web Store entirely, with existing installs stuck unable to update. The core technical shifts — service workers, declarativeNetRequest, no remote code, stricter host permissions — are permanent parts of the extension platform going forward. For most extensions the migration is mechanical but real work; for a narrow set of use cases, particularly deep content and ad blocking, MV3's constraints represent a genuine capability loss that alternative browsers are now positioned to capitalize on.

Sources:

• Manifest V2 support timeline — Chrome for Developers
• Extensions / Manifest V3 — Chrome for Developers
• Resuming the transition to Manifest V3 — Chrome for Developers Blog
• Manifest V2 phase-out begins — Google Chromium Blog
• uBlock Origin on Chrome in 2026: Manifest V3 Status
• The last lifeline for uBlock Origin in Chrome is almost gone for good — PCWorld