Why Is My Chrome Extension Disabled? The Manifest V2 Deadline Explained

If Chrome suddenly disabled one of your extensions — or one you published stopped working for your users without warning — the most likely cause in 2026 is not a bug. It is Manifest V2. Chrome has been phasing out support for Manifest V2 extensions in favor of Manifest V3, and the rollout does not ask permission: it disables the extension in the browser and shows a generic warning, leaving both users and developers to figure out why.

This guide explains what is actually happening, how to tell if it is affecting your extension, and what a developer needs to do about it — whether that means finishing a migration you have been putting off, or explaining to users why an old favorite just went gray. If you searched "chrome extension disabled" hoping for a straight answer, this is it: Manifest V2 retirement is the top cause, and the rest of this guide covers how to confirm it and fix it.

If you're a user, not the developer

Short answer: you cannot manually re-enable it. The toggle in chrome://extensionswill not stay on — Chrome disables Manifest V2 extensions at the platform level, not per-user. The extension itself is not broken and your data is not gone; it is waiting on the developer to publish a Manifest V3 update. Check the extension's Chrome Web Store listing for a recent update or an announcement — if one exists, install it. If the developer has gone quiet, look for an actively maintained alternative that does the same job; do not wait indefinitely on an extension with no update in a long time.

Why is my Chrome extension disabled?

Manifest V2 is the older extension platform format. Manifest V3, introduced years ago, is Chrome's replacement — built around a more restrictive extension model: background pages become service workers, remote code execution is blocked, and network-request interception moves from the flexible webRequest API to the more limited declarativeNetRequest API. Chrome has been retiring Manifest V2 support in stages, first showing warnings in the Chrome Web Store and developer dashboard, then disabling affected extensions in the browser itself once the deadline for a given distribution channel passes.

The practical effect for anyone still shipping Manifest V2: Chrome disables the extension automatically. Users see it listed as disabled in chrome://extensions, often with no clear explanation beyond a note that it is no longer supported. Nothing was uninstalled — the code and settings are still there — but the extension stops running until it is migrated to Manifest V3 and republished.

A disabled Chrome extension is not a removed extension. The listing, install base, and reviews survive. What is gone is the ability to run — and every day it stays disabled is a day of silent churn you cannot see without tracking it.

How to tell if your extension is affected

Three places show the status, each from a different angle:

• Your Chrome Web Store developer dashboard. Extensions still on Manifest V2 are flagged there with a migration warning well before the enforcement deadline for your distribution channel.
• chrome://extensions in your own browser. Load the page — a disabled Manifest V2 extension shows as toggled off, usually with a short explanation link.
• Your own manifest.json. The single fastest check: open manifest.json in your extension's source and look at the "manifest_version" field. 2 means you are exposed; 3 means you already migrated.

If you maintain more than one extension, check each one separately — it is common for a developer's newer extension to already be on Manifest V3 while an older, half-maintained listing is still quietly running Manifest V2 and heading for the same deadline.

What actually breaks when you migrate to Manifest V3

Migration is not a version-number edit. The features most likely to need real rework:

The declarativeNetRequestchange is the one generating the most public friction: extensions that block ads or trackers by inspecting and modifying requests in real time have to redesign around a fixed, declared rule set, and some capability is genuinely lost in the process. That is why "manifest v3 ad blocker" searches keep showing up — users trying to understand why their ad blocker got weaker after an update, and developers looking for how much of their old blocking logic can survive the migration.

Migrating: the practical checklist

1. Bump manifest_version to 3 and update the manifest keys that changed shape (background, action vs. browser_action/page_action, host_permissions).
2. Convert your background page to a service worker. Move any state you relied on keeping in memory into chrome.storage, since a service worker can be unloaded and restarted at any time.
3. Replace blocking webRequest calls with declarativeNetRequest rules, or redesign the feature around what static rules can express.
4. Split permissions and host_permissions — Manifest V3 separates the two, and over-broad host_permissions (like <all_urls>) draw more review scrutiny and more user-facing permission warnings than before.
5. Remove remote code loading and inline scripts, bundling every script the extension needs inside the published package.
6. Test the migrated build thoroughly before submitting — a broken resubmission after users are already disabled compounds the damage.
7. Publish the update and watch the review queue closely — a migration touches permissions and code structure, both of which get extra scrutiny in review.

The part most guides skip: what happens to your listing while you migrate

A disabled extension does not disappear from the Chrome Web Store, and it does not stop being ranked or shown in search the instant it gets disabled in browsers — but the damage compounds quietly. Users who cannot use the extension anymore uninstall it, leave a one-star review explaining why, or simply stop being active — all signals the store's ranking weighs. By the time your Manifest V3 build ships, you may be climbing back from a worse position than the one you left, not the one you had before Chrome flipped the switch.

This is also exactly the situation where a slow-moving competitor becomes an opportunity. If a competing extension in your category is still on Manifest V2 and has not migrated, their listing is on a countdown you can watch from the outside — install counts flattening or dropping, ratings sliding, keyword positions opening up as their traffic and engagement signals weaken.

If you maintain an extension that will not migrate

Not every Manifest V2 extension has an owner still actively maintaining it. If yours is abandoned, forked from something else, or you have decided to sunset it, the honest move is to update the store listing to say so — rather than leaving users to discover a disabled, unexplained extension and search for "chrome extension no longer supported" looking for answers you never gave them. A short, clear listing update and a pointer to an alternative (yours or someone else's) costs little and protects the reputation attached to your developer account for every other extension you publish.

If you are actively migrating, treat the deadline as a hard product deadline, not a someday task. Check your manifest_version today, budget real engineering time for the declarativeNetRequest and service-worker changes if they apply to you, and once the new version is live, track the recovery the same way you would track a launch — because to the store's ranking signals, that is exactly what it is.