Manifest V3 Chrome Extensions: What Changed (2026)

Manifest V3 is the rulebook that every Chrome extension now follows. It defines how an extension is packaged, what it may ask for, how it runs code in the background, and how it is allowed to interfere with network requests. The migration from Manifest V2 stretched across several years, generated more argument than any other change in the extension platform history, and is now finished in consumer Chrome — Manifest V2 extensions were disabled through a staged rollout and the enterprise policy that deferred that shutdown has expired.

If you are a user, manifest v3 chrome extensions explain several things you probably noticed: an extension that suddenly stopped working, a content blocker that asked you to switch to a "Lite" version, and permission prompts that now appear per site rather than once at install. If you are a developer, they define the constraints you are building inside. This guide covers both, without the advocacy that dominated the debate while it was live.

What Manifest V3 Actually Is

An extension is a folder of files with a manifest at the root describing what the folder contains and what it needs. The manifest declares a version number — "manifest_version": 3 — and that number selects which platform rules apply.

Manifest V2 governed extensions from 2012 until the migration. Manifest V3 was announced in 2018, opened for submissions in 2020, and became mandatory for new Chrome Web Store submissions in January 2022. Existing V2 extensions were removed from store search, then disabled in browsers in stages, with enterprise deferral available for a limited period that has since ended.

Four changes carry nearly all the practical consequences:

1. Background pages became service workers. Extensions no longer keep an always-running page in memory.
2. Blocking network interception became declarative. Extensions describe rules to the browser instead of inspecting each request themselves.
3. Remotely hosted code was banned. Every line of executable code must ship inside the package that was reviewed.
4. Host permissions became runtime-grantable. Users can restrict an extension to specific sites or to click-activation.

Everything else is API renaming and cleanup. These four are the substance of what separates manifest v3 chrome extensions from the generation that preceded them.

Change 1: Service Workers Replace Background Pages

Under Manifest V2, an extension could declare a persistent background page — an invisible HTML document that stayed loaded for as long as the browser ran. It had a DOM, it kept variables in memory indefinitely, and it consumed memory whether or not the extension was doing anything.

Manifest V3 replaces it with an extension service worker. The model is event-driven:

• It starts when an event fires — a keyboard command, a message from a content script, an alarm, a tab update.
• It runs the handler and then shuts down after a period of inactivity.
• It has no DOM. No document, no window object, no direct DOM parsing.
• It keeps no state between wakeups. Anything that must survive goes into the storage API.

For developers this is the single largest behavioral change, and the most common source of migration bugs. Code that stored a value in a module-level variable and read it back later works fine in testing, where the worker has not yet been terminated, and fails in the wild after the worker restarts. The fix is not clever — write to chrome.storage and read from it — but the bugs it causes are intermittent and therefore expensive to find.

Chrome softened the original behavior over time in response to developer feedback, extending how long a worker survives while it is actively handling events and while a message port stays open. The general principle still holds: design for a background script that can vanish between any two events.

For a simple tool the constraint costs nothing. An extension whose whole job is to respond to a keyboard command and write to the clipboard has no state worth persisting, so the service worker model fits it exactly. The Ctrl+Shift+C extension is that shape — a command listener, a clipboard write, nothing held in memory, no network calls, no data collection. Small tools were largely unaffected by the migration that broke complex ones.

Change 2: Declarative Blocking Replaces Request Interception

This is the change that generated the argument.

Under Manifest V2, an extension with the blocking form of the webRequest API could register a listener that ran on every network request the browser made, inspect the full request, and decide synchronously whether to allow, block, or redirect it. That is enormous power. It is also, by construction, complete visibility into everything the browser fetches.

Manifest V3 replaces the blocking form with declarativeNetRequest. The extension registers rule sets — patterns and actions — and the browser evaluates them itself. The extension never sees the individual requests unless it separately holds permission to observe them.

What this improves. The browser can evaluate rules in native code without waiting on extension JavaScript, which removes a per-request latency cost and a class of extension-induced slowdowns. It also removes the extension ability to read the contents of every request as a side effect of blocking, which is a genuine privacy improvement given that request interception was also a known abuse vector.

What this costs. Rules must be expressible in the declarative format, and there are numeric limits on how many static and dynamic rules an extension may register. Filtering techniques that depended on inspecting a response, or on logic more complex than the rule format can express, cannot be reproduced exactly. Chrome raised the rule limits during the migration in response to filter-list maintainers, but the expressiveness ceiling remains.

What it means in practice. Mainstream content blocking works. uBlock Origin in its full form is a Manifest V2 extension and is therefore unavailable in current Chrome; its author ships uBlock Origin Lite, built on declarative rules, which handles standard filter lists but not the full set of advanced features. Users who depend on the advanced features moved to Firefox, which kept the blocking webRequest API. Users who wanted mainstream blocking generally did not notice the difference beyond a one-time switch.

Both positions in the original argument turned out to be partly right, which is why the debate never resolved cleanly.

Change 3: No Remotely Hosted Code

Under Manifest V2, an extension could load and execute JavaScript fetched from a server after installation. The reviewed package and the running code could therefore be different, and an extension could be benign at review time and malicious a week later without shipping an update.

Manifest V3 prohibits it. All executable code must be contained in the package submitted for review. Extensions can still fetch data — configuration, filter lists, content — but not code to execute.

Of everything that defines manifest v3 chrome extensions, this is the least controversial change and arguably the most valuable. It closes the gap between what the reviewer saw and what runs on your machine. It does not make review perfect, but it makes an update the only path to changed behavior, and updates are reviewable.

The practical consequence for developers: anything that used to be delivered as a remote script now needs to ship in the bundle or be redesigned as data plus a local interpreter. The practical consequence for users: an extension cannot silently become something else between updates.

Change 4: Host Permissions Became Grantable at Runtime

Under Manifest V2, host permissions were typically granted wholesale at install. You accepted the "read and change all your data on all websites" prompt or you did not install.

Manifest V3 separates host permissions into their own manifest field and encourages patterns where the user grants access per site or on click. In practice this shows up as the site access control in the extension details page, where you can set an extension to run on click, on specific sites, or on all sites. The activeTab permission remains the cleanest pattern for tools that only need access to the page when you deliberately invoke them.

This is a real improvement in user control, with a caveat: the enforcement is about when access is granted, not about how much an extension can do once it has access. An extension you grant all-sites access to under Manifest V3 sees exactly as much as it would have under V2. The change makes the smaller option available and visible, not automatic. The related privacy reasoning is covered in privacy focused chrome extensions.

What Users Actually Noticed

Stripped of the platform detail, manifest v3 chrome extensions produced four visible effects for ordinary users.

Some extensions disappeared. Abandoned Manifest V2 extensions with no maintainer to migrate them were disabled and never came back. If a tool you relied on vanished during the rollout, this is almost certainly why.

Content blockers changed. Either the extension shipped a rebuilt declarative version, or it asked you to install a Lite variant, or it stopped working. Most people saw a one-time transition and little else.

Permission prompts became more granular. More extensions now ask for site access at the moment they need it rather than demanding everything at install.

Background memory use dropped. Extensions no longer hold a persistent page each. On a browser with a dozen extensions installed this is a measurable difference, though far less than the effect of the tabs you have open.

What most users did not notice: almost everything else. Small single-purpose tools migrated with little visible change, because they were already event-driven and already asked for narrow permissions. This is one of several reasons the tiny chrome extensions category came through the transition intact while heavier tools struggled.

Manifest V3 vs. Manifest V2: The Honest Comparison

A fair summary of the trade between manifest v3 chrome extensions and their predecessors, without picking a side.

Manifest V3 is better at: preventing post-review code changes, reducing idle memory use, giving users per-site control over access, and removing an API whose blocking form gave every content blocker complete visibility into all traffic.

Manifest V2 was better at: expressive network filtering, straightforward background state management, and being a stable target that did not require every extension in the ecosystem to be rewritten.

Where reasonable people still disagree: whether the declarative model constrains content blocking enough to matter for real users, and how much weight to give the fact that the platform vendor also sells advertising. Both arguments are made in good faith. The answer for any individual comes down to whether they used advanced filtering features or just wanted the ads gone.

Where the disagreement is settled: the migration is complete. Manifest V2 is not a supported target for consumer Chrome, and building against it is building for other browsers. Firefox supports Manifest V3 while retaining the blocking webRequest API, so cross-browser extensions can target V3 broadly and use the richer API where it exists.

What Manifest V3 Means If You Are Building an Extension

For a developer starting today, all new work targets manifest v3 chrome extensions by default. There is no decision to make about version. The constraints that shape design:

• Assume the service worker dies. Any state that must survive belongs in chrome.storage. Test by manually terminating the worker from the extensions page and confirming your extension still behaves.
• Register listeners at the top level. Event listeners must be registered synchronously when the worker starts, not inside an async callback, or events that wake the worker will find nothing listening.
• Use chrome.scripting for injection. The old tabs-based execute methods are gone.
• Prefer activeTab over broad host permissions. It is a better user experience, a faster review, and a smaller blast radius.
• Ship all code in the package. Configuration and data can be fetched; code cannot.
• Use promises. The Manifest V3 APIs return promises, so callback-style code is no longer necessary.
• Declare only what you use. Every permission in the manifest appears in the install prompt and in the store listing, and every unnecessary one costs installs.

A step-by-step build walkthrough that puts these together into a working extension is in how to build a chrome extension.

How to Check What an Extension Is Running

Two practical checks.

For anything installed from the store. If it works in current Chrome, it is one of the manifest v3 chrome extensions. There is no ambiguity left — the V2 shutdown removed the alternative.

For unpacked or open-source extensions. Open the manifest file at the package root and read the manifest version field. In an open repository this file is usually the first thing in the source tree and is worth reading regardless, because it lists exactly which permissions the extension declares. For a small tool the entire manifest fits on one screen, and reading it tells you more about what the extension can do than any description will.

You can also open chrome://extensions, enable Developer mode, and inspect the service worker of any installed extension to see what it does when it wakes up. That is a deeper level of scrutiny than most people need, but it is available.

Frequently Asked Questions

What is Manifest V3 in simple terms? It is the current specification that defines how a Chrome extension is structured and what it is permitted to do. It replaced Manifest V2 and changed four things that matter: background execution became event-driven, network blocking became declarative, remotely hosted code was banned, and host permissions became grantable per site at runtime.

Why did Google move extensions to Manifest V3? The stated reasons were security, privacy, and performance. Banning remotely hosted code closes the gap between reviewed and running code. Replacing the blocking webRequest API removes an interface that gave extensions visibility into every network request. Removing persistent background pages reduces idle memory use across the browser.

Did Manifest V3 break ad blockers? It changed how they are built rather than eliminating them. Blocking now runs through declarative rule sets that the browser evaluates, which is faster and more private but less expressive than arbitrary code inspecting each request. Standard filter lists work; some advanced filtering techniques cannot be expressed in the declarative format.

Can I still use a Manifest V2 extension in 2026? Not in normal consumer Chrome. The staged shutdown disabled Manifest V2 extensions and the enterprise policy that allowed temporary deferral has expired. Some other Chromium-based browsers maintained support for longer, and Firefox retains the blocking webRequest API under its own Manifest V3 implementation.

What is a service worker in a Chrome extension? It is the background script under Manifest V3. It wakes when an event fires, handles it, and terminates when idle. It has no DOM and retains no in-memory state between wakeups, so anything that must persist has to be written to extension storage.

Does Manifest V3 make extensions safer to install? It raises the floor. Code cannot change after review without an update, and users can restrict site access per site or to click-activation. It does not change what an extension can see on pages where you have granted it access, so reading the permission list before installing still matters as much as it ever did.

How can I tell which manifest version an extension uses? Anything currently working in Chrome from the Web Store is Manifest V3. For an unpacked or open-source extension, open the manifest file in the package root and read the manifest version field, which also shows the full permission list in one place.

Install Small, Read the Manifest

The Manifest V3 transition rewarded a particular kind of extension: small, event-driven, narrow in permissions, with all its code in the package and nothing loaded from a server. Those tools migrated quietly while complex ones were rebuilt or abandoned. That is a useful signal about what to install going forward, independent of any platform version.

Ctrl+Shift+C is built exactly to that shape — a command listener that copies the current tab URL to the clipboard, clipboard permission only, no host permissions, no network calls, no data collection, nothing that a manifest version change could break. Install it, then spend two minutes reading the permission lists of the other extensions you rely on. Under manifest v3 chrome extensions, that list is the most honest description of what a tool can do.