MV2 Deprecation Timeline and Enterprise Exceptions

“Do we still need to support MV2?” and “Can our enterprise customers keep the old version?” are the two questions every team with a long-lived extension asks during migration. The answers differ by browser, and they changed several times as Chrome’s phase-out slipped and then proceeded in stages. This guide lays out where MV2 stands in each engine, what the enterprise exception was and why it ended, and how to decide what to build. It belongs to Manifest V2 to V3 migration.

How the phase-out unfolded

Chrome announced MV3 in 2019, stopped accepting new MV2 extensions on the Chrome Web Store in 2022, and then postponed the shutdown of existing ones while the MV3 platform filled gaps — offscreen documents, longer service worker lifetimes, user scripts, higher rule limits. The shutdown itself began in mid-2024: MV2 extensions were first flagged with warnings, then disabled for users in stages across Chrome releases, with a temporary option to re-enable them. Enterprises received a policy, ExtensionManifestV2Availability, that kept MV2 working in managed browsers for roughly a further year. By mid-2025 that exception had ended and stable Chrome no longer runs MV2 extensions at all. Chromium derivatives followed on their own schedules, Firefox committed to keeping MV2, and Safari supports both.

Step-by-step: plan your support matrix

1. Check what your users actually run

1// sw.js — record engine and major version once per day, anonymously
2chrome.alarms.create("ua-sample", { periodInMinutes: 24 * 60 });
3chrome.alarms.onAlarm.addListener(async ({ name }) => {
4  if (name !== "ua-sample") return;
5  const brands = navigator.userAgentData?.brands ?? [];
6  const brand = brands.find((b) => !/Not.A.Brand|Chromium/.test(b.brand)) ?? brands[0];
7  await reportCount("engine", { brand: brand?.brand ?? "unknown", major: brand?.version ?? "?" });
8});

Execution context: the service worker of your current (MV2 or MV3) build. navigator.userAgentData is available in Chromium workers; Firefox lacks it and the fallback is navigator.userAgent. Coarse, opt-in, aggregated counts — engine and major version only — are enough to see how many users are on browsers that still accept MV2, and fit within a privacy policy that discloses usage statistics. See privacy-preserving usage metrics.

2. Map each browser to a manifest version

1Chrome (stable, consumer and managed)   MV3 only
2Edge                                    MV3 (MV2 phased out following Chromium)
3Brave / Opera / Vivaldi                 MV3 (Chromium core; some keep limited MV2 support for longer)
4Firefox                                 MV2 or MV3 — both supported, no MV2 end date announced
5Safari                                  MV2 or MV3

Execution context: a planning document, not code. Chromium derivatives inherit the platform change but decide their own timelines and policies; check each vendor’s current statement before promising MV2 support to their users. For a new build, MV3 everywhere is the simplest answer and the only one that works in Chrome.

3. Decide whether to keep an MV2 build for Firefox

Firefox’s continued MV2 support is a real option, notably for extensions that depend on blocking webRequest with arbitrary logic. But Firefox’s MV3 also keeps blocking webRequest, so the most common reason to stay on MV2 there no longer applies. The cost of an extra build is maintenance: two background architectures, two manifests, two test matrices.

1// One codebase: feature-detect the capability, not the manifest version
2const canBlock = typeof browser !== "undefined"
3  && browser.runtime.getManifest().manifest_version >= 2
4  && browser.webRequest?.onBeforeRequest
5  && browser.runtime.getURL("").startsWith("moz-extension:");

Execution context: the background of a cross-browser build. A single MV3 codebase with a Firefox-specific module for blocking webRequest gives Firefox users the richer behaviour without a second architecture. Keep MV2 for Firefox only if a dependency genuinely cannot run in its MV3 event page.

4. Tell enterprise customers what changed

Managed deployments were the last to lose MV2 and are often the least aware. They install extensions through ExtensionInstallForcelist, frequently pin versions, and may have been running the old build under the exception policy for a year. When it ended, the extension stopped running for their whole fleet at once.

1{
2  "ExtensionSettings": {
3    "abcdefghijklmnopabcdefghijklmnop": {
4      "installation_mode": "force_installed",
5      "update_url": "https://clients2.google.com/service/update2/crx",
6      "minimum_version_required": "4.0.0"
7    }
8  }
9}

Execution context: an enterprise policy file or admin console. minimum_version_required lets an administrator ensure every machine runs at least your first MV3 release, and disables older versions until they update. Publish a short admin note with your MV3 release explaining the version to require, any new permissions, and any changes to managed-storage configuration keys, as covered in configuring extensions with enterprise managed storage.

5. Retire the MV2 code path deliberately

1# Before deleting: confirm no active MV2 installs remain in your telemetry, then
2git rm -r src/background-mv2 manifests/mv2.json
3git commit -m "Remove MV2 build; all targets now MV3"

Execution context: your repository. Leaving dead MV2 code in the tree invites accidental use — a shared helper that still references chrome.extension.getBackgroundPage, a test suite that still builds both. Delete it in one reviewed change once your user data shows the MV2 build has no meaningful population left.

Common mistakes

• Trusting an old blog post’s dates. The phase-out schedule moved several times. Check the vendor’s current documentation rather than a dated article — including this one, which describes the state as of its last update.
• Assuming Edge, Brave and Opera match Chrome exactly. They follow Chromium broadly but set their own policies and timelines.
• Keeping MV2 for Firefox by default. It doubles maintenance; Firefox’s MV3 retains the capability most teams stayed on MV2 for.
• Not notifying administrators. Enterprise fleets lose an extension all at once when an exception ends. A short, specific admin note prevents the support flood.
• Pinning minimum_chrome_version too low. MV3 features such as offscreen, userScripts or longer worker lifetimes need specific versions; declare the minimum you actually use.

Cross-browser variation

• Chrome / Edge: MV3 only in stable channels; the Chrome Web Store and Edge Add-ons do not accept MV2 updates.
• Firefox: MV2 and MV3 both supported, with MV3 retaining blocking webRequest. AMO accepts either.
• Safari: MV2 and MV3 supported; conversion with Xcode’s Safari web extension converter works from either.

Verification

1. Check your build matrix: Chrome and Edge artefacts declare "manifest_version": 3.
2. Confirm your store listings show the MV3 version as the current release in every Chromium store.
3. Ask an enterprise customer (or test with a managed profile) to apply minimum_version_required and confirm older versions are disabled.
4. Review telemetry for MV2 installs before removing the MV2 code path.

FAQ

Can users still sideload an MV2 extension in Chrome?

Not in stable Chrome. Developer-mode loading of unpacked MV2 extensions has also been removed along with the rest of MV2 support.

Will Firefox ever drop MV2?

Mozilla has said it will continue to support MV2 alongside MV3 and has not announced an end date. Plan for that to remain true, but do not build a strategy that depends on it forever.

Do Chromium forks keep MV2 longer?

Some have kept limited support for longer, particularly for content blockers. It is vendor-specific and subject to change; check each one.

What should the extension do if it detects an unsupported environment?

Very little — an MV3 extension cannot run in a browser that does not support MV3, so it never sees that case. The useful check is the opposite one: if your telemetry shows users on browser versions below your minimum_chrome_version, the store simply will not offer them updates, and they stay on whatever version they last received. Publish a support note that names the minimum browser version so those users know to update the browser rather than reinstall the extension.

Related

• MV2 to MV3 migration checklist — the work the timeline forces.
• Publishing private and enterprise extensions — managed distribution in detail.
• Background script support across browsers — what each engine runs in MV3.
• Manifest V2 to V3 migration — the parent topic.