Chrome Extension Manifest V3: What Actually Changed

Chrome Manifest V3 is the extension platform format every Chrome extension is expected to use now — Manifest V2 support has been phased out and is being disabled in stages (see our guide on why extensions get disabled if that is what brought you here). This guide is for the other half of the question: once you are on Manifest V3, what actually changed in how your extension is built, and does any of it affect how the extension ranks and is discovered?

For scale: 244,729 of the 260,982 extensions in our store index — 93.8% — now declare Manifest V3, while 11,450 are still on Manifest V2. Manifest V3 is no longer the new thing to plan for; it is what almost the whole catalogue already ships. Counts come from our own index, described on our about page.

When was Manifest V3 released, and when did Manifest V2 stop working?

Manifest V3 has no single release date, and looking for one is what makes the timeline confusing. It arrived as a gradual rollout, in four milestones years apart. First the format was published and Chrome began accepting Manifest V3 submissions. Then the Chrome Web Store stopped accepting new Manifest V2 submissions. Warnings followed, in the store listing and the developer dashboard. Finally Chrome began disabling Manifest V2 extensions in the browser itself, channel by channel.

That last phase is what most people mean when they ask about the deadline, and it is the one that was staged rather than switched: pre-stable channels first, then stable, with enterprise deployments given a separate extension through policy. Because the dates moved more than once during the rollout, the only version worth trusting is Google's own Manifest V2 deprecation timeline, which it keeps current. Do not plan a migration around a date quoted in a blog post — including this one.

There is no Manifest V3 release date to point at. There is a phased Manifest V2 shutdown, and the only question that matters for your extension is which phase your distribution channel is in.

If your extension has already stopped running for users, the timeline is no longer your problem and the fix is — see why Chrome disabled your extension.

What does Manifest V3 change for a Chrome extension?

• Background pages become service workers. No more persistent background page holding state in memory — a service worker can be stopped and restarted by Chrome at any time, so anything you need to survive has to live in chrome.storage, not a JS variable.
• webRequest (blocking) is replaced by declarativeNetRequest. Instead of intercepting and deciding on every network request at runtime, you declare rules ahead of time. This is the single biggest behavioral change, and the one with the most public friction — see the next section.
• Remote code is no longer allowed. Every script the extension runs has to ship inside the reviewed package. No more pulling logic from your own server post-install.
• host_permissions is now separate from permissions. Site access is called out on its own, which also means it is called out more clearly to users and reviewers.
• A stricter default content security policy blocks inline scripts and eval-style dynamic code execution by default.

For the authoritative field-by-field spec, Chrome's own Manifest V3 migration guide and declarativeNetRequest API reference are worth keeping open while you work — this guide covers what those changes mean in practice, not a substitute for the reference docs.

What the manifest itself looks like, before and after

Most of the migration is mechanical manifest surgery. A minimal Manifest V2 background entry and its Manifest V3 equivalent:

The background and action key renames are simple find-and-replace. The host_permissions split is the one worth reading carefully — anything that looks like a URL pattern in your old permissions array needs to move.

A minimal Manifest V3 manifest.json

If you want a working starting point rather than a diff, this is close to the smallest useful Manifest V3 file — a popup, a service worker, one content script, and deliberately narrow access:

{
  "manifest_version": 3,
  "name": "Example Extension",
  "version": "1.0.0",
  "description": "One sentence describing what it does.",

  "action": {
    "default_popup": "popup.html",
    "default_icon": { "16": "icons/16.png", "128": "icons/128.png" }
  },

  "background": { "service_worker": "background.js" },

  "content_scripts": [
    { "matches": ["https://example.com/*"], "js": ["content.js"] }
  ],

  "permissions": ["storage"],
  "host_permissions": ["https://api.example.com/*"],

  "icons": { "16": "icons/16.png", "48": "icons/48.png", "128": "icons/128.png" }
}

Two things in that file are choices, not boilerplate. "matches" is scoped to one origin rather than <all_urls>, and host_permissions names a single API host. Both could be widened in one character, and both are what a user is shown at the install prompt — which is the part of the manifest that quietly decides whether people complete the install at all.

Where the official Manifest V3 documentation is — and what it leaves out

Almost every Manifest V3 question has an authoritative answer on developer.chrome.com, and it is worth knowing which page holds which answer instead of searching the whole site each time.

What the documentation deliberately does not cover is the consequences. It specifies that host_permissions is separate from permissions; it does not tell you that widening it in an update triggers a re-consent prompt and a wave of uninstalls. It documents the service worker lifecycle; it does not tell you that the resulting bug usually reaches you as a one-star review rather than an issue report. Those are the gaps this guide and the rest of the cluster are for.

Manifest V3 in Chromium browsers other than Chrome

Manifest V3 is a Chromium platform change, not a Chrome-only one, so every Chromium-based browser inherits it — but not on the same schedule and not with identical behaviour.

• Microsoft Edge takes the same format; a Manifest V3 package generally submits to the Edge Add-ons store unchanged. Microsoft keeps its own Manifest V3 guidance and its own deprecation schedule, which has not always matched Chrome's.
• Brave, Opera, and Vivaldi ship on Chromium and therefore inherit the engine-level changes, but several have said they will keep supporting parts of the Manifest V2 blocking APIs in their own builds for longer than upstream Chrome. That affects which of your users keep working, not what you are allowed to publish to the Chrome Web Store.
• Firefox is not Chromium. It supports Manifest V3 with a deliberately different stance — notably keeping blocking webRequest alongside declarativeNetRequest — so a straight port is not automatic.

The practical takeaway: build for Chrome's rules, because they are the strictest and the store you cannot skip, then treat every other store as a distribution question rather than a second migration.

Does Manifest V3 itself affect Chrome Web Store ranking?

Not directly — manifest_version is not a documented ranking signal, and there is no evidence Google boosts Manifest V3 listings simply for being on the newer format. Where Manifest V3 affects ranking is indirect, through the same signals that always mattered:

In other words: Manifest V3 will not move your position by itself, but botching the migration — or ignoring it past the deadline — absolutely will, through the same ordinary engagement and rating mechanics that decide ranking generally.

The service worker lifecycle catches almost everyone once

This is the single most common Manifest V3 bug, and it rarely shows up in local testing. A Manifest V2 background page stayed alive for as long as Chrome itself ran, so code that set a variable once and read it later worked fine. A Manifest V3 service worker is event-driven: per the service-worker lifecycle docs, Chrome can and will terminate it after roughly 30 seconds of inactivity, and spin up a fresh instance — with a clean, empty memory space — the next time an event fires.

Concretely: any in-memory variable, cache, or counter your background logic relies on will silently reset the first time the service worker is unloaded, which in production can be minutes after install. The fix is not exotic. Move that state into chrome.storage.local or chrome.storage.session, and read it back at the top of every event handler rather than assuming it survived. What makes it easy to miss is local testing: while you are debugging, the service worker happens to stay warm the whole time.

Manifest V3 does not reward you for migrating. It only punishes you for not migrating, or migrating badly — and the service worker lifecycle is where "badly" most often hides. Treat it as maintenance with a deadline, not a feature launch.

For the full step-by-step checklist — bumping manifest_version, converting the background page, replacing webRequest, trimming host_permissions, testing, and publishing — see the Manifest V2 deprecation guide, which walks through it in order.

What to watch after you ship the migration

A migration touches enough surface area — background behavior, permissions, network logic — that it deserves the same scrutiny as a normal version release. Watch install trend, rating trend, and your keyword positions for the two weeks after the update goes live, in every language you publish your listing in — not just the one you happen to search in.

Two of those signals are worth pinning to the release that caused them. The version your users are actually running tells you how fast the migration propagated — a store listing flips to the new build immediately, installed copies do not. And if you widened host_permissions during the port, the resulting re-consent prompt is its own event: expect a dip that has nothing to do with whether your code works. Watch both against the release date rather than against the month, and the two effects stay separable. You can follow your published version, user count, ratings, and keyword positions over time on cwspy.com, and collect the reasons behind any dip with an uninstall feedback page.

If your extension is a content or ad blocker, the declarativeNetRequest change deserves its own read — see Manifest V3 and ad blockers for what is and is not possible to rebuild.