Chrome Removes Every Manifest V2 Extension on 31 August 2026

On 31 August 2026, Google removes every remaining Manifest V2 extension from the Chrome Web Store.

If you are reading that as a warning, you have misread it. It is the last step of something that finished thirteen months ago.

Your extension did not break this month. It broke last July.

Almost every article about 31 August frames it as the day Manifest V2 extensions stop working. That is not what happens, and the difference matters if you own one.

Google's own deprecation timeline is clear. On 24 July 2025, with Chrome 138, Manifest V2 extensions were disabled for all users on all channels, and users lost the ability to turn them back on. Chrome 138 is the final version of Chrome that supported Manifest V2 at all. The ExtensionManifestV2Availability enterprise policy, which had been the last remaining exemption, was removed in Chrome 139.

So the functional end came over a year ago. What happens on 31 August 2026 is that the listings themselves are deleted.

If your extension is still on Manifest V2, it has not run in a user's browser for 397 days. Whatever you thought it was doing during that period, it was not doing. The only question left is whether you also lose the store asset.

This is the reason some owners have not noticed. An extension that quietly stopped firing does not raise a support ticket the way a broken login does. Internal tools stop syncing and someone starts doing the task by hand. A partner integration stops posting and nobody attributes it to the browser.

Four years of notice, in order

Dates below are from Google's published Manifest V2 deprecation timeline, not from secondary coverage.

Worth noting for anyone who deployed by policy: the enterprise escape hatch is gone, not deprecated. There is no supported configuration in current Chrome that will run a Manifest V2 extension, including on managed devices.

The listing is the asset, and the listing is what goes

Since the extension already does not run, the loss on 31 August is commercial rather than technical. For a product extension that distinction is expensive.

• The store URL. Every link to it from your website, your documentation, your onboarding emails and your sales deck stops resolving.
• The review and rating history. Years of accumulated social proof, gone in one step. A new listing starts at zero reviews.
• The install count. The number that told a prospect other people trusted this, and the number your team quoted in pitches.
• Store search placement. Whatever ranking the listing had accumulated for its category and keywords.
• Deployment by item ID. Enterprise administrators who force-install your extension by ID across their fleet reference the store item. Remove the item and that deployment path has nothing to point at.

Google's timeline states that remaining MV2 extensions are removed. It does not say whether a removed item can be brought back by uploading a Manifest V3 version to the same listing, and we have not seen that documented anywhere.

If you own an MV2 item you care about, publish an MV3 update before the 31st rather than finding out. Review times are not instant, and a question with no published answer is a poor thing to bet a listing on.

How to tell in ten minutes whether this applies to you

Most owners of an affected extension are not extension developers. They commissioned one, three or four years ago, from someone who has since moved on. Here is how to check without involving anybody.

1. Open the source, if you have it. The manifest is one line. Anything other than 3 is affected.

grep manifest_version manifest.json
# "manifest_version": 2,   <- affected

3. Check the Chrome Web Store developer dashboard. Sign in with the account that published the item. If nobody at your company knows which account that is, that is the more urgent problem, and it is worth solving today rather than on 1 September.

4. Look for the work the extension used to do. If it wrote to a database, posted to an API, or filed records, check whether anything has arrived since July 2025. Silence there confirms it.

If your manifest already says 3, you are finished. Nothing on 31 August affects you, and no action is required. Most of what is written about this deadline is aimed at people who are already compliant, which is why it is worth taking ten minutes to establish which group you are in.

Why this is a rewrite and not a version bump

The name suggests a manifest edit. It is not. Manifest V3 changed the execution model, and four of those changes routinely break assumptions that were reasonable when the extension was written. None of this reflects badly on whoever built it. These were correct patterns under MV2.

1. The background page became a service worker

A Manifest V2 background page could be persistent. It stayed loaded, held state in memory, and ran timers. A Manifest V3 service worker is event driven and terminates on inactivity, then restarts when the next event arrives.

Every global variable in the old background script is a bug waiting to appear. It will often work in testing, because the worker is still warm, and fail in production once it has been idle.

// MV2. This survived indefinitely.
let sessionToken = null;

chrome.runtime.onMessage.addListener((msg) => {
  if (msg.type === "login") {
    sessionToken = msg.token;
  }
});

// MV3. State must leave the worker.
chrome.runtime.onMessage.addListener(async (msg) => {
  if (msg.type === "login") {
    await chrome.storage.session.set({ sessionToken: msg.token });
  }
});
// storage.session is in memory and cleared when the browser
// closes, which suits tokens. Use storage.local to persist.

The same termination rule kills timers. setTimeout and setInterval are cancelled whenever the worker shuts down, so any scheduled work has to move to the Alarms API, whose minimum period is measured in minutes rather than seconds.

// MV2
setInterval(syncNow, 5 * 60 * 1000);

// MV3
chrome.alarms.create("sync", { periodInMinutes: 5 });
chrome.alarms.onAlarm.addListener((a) => {
  if (a.name === "sync") syncNow();
});

There is one more trap here that produces intermittent, hard to reproduce failures. Event listeners must be registered synchronously at the top level of the script. Register one inside a callback or after an await and the worker may well have finished initialising before it exists, so the event is simply missed.

// Fails intermittently. The listener is registered too late.
chrome.storage.local.get("config", (cfg) => {
  chrome.tabs.onUpdated.addListener(handler);
});

// Correct. Top level, synchronous, before any await.
chrome.tabs.onUpdated.addListener(handler);

2. Blocking webRequest became declarativeNetRequest

This is the change that decides whether a migration takes a week or a quarter.

Under MV2, an extension could intercept a request and run arbitrary JavaScript to decide what to do with it. The decision could depend on anything: user settings, a list fetched from your server that morning, a computation over the page's state.

Under MV3 you declare rules and Chrome enforces them. Your code is not consulted at request time.

// MV2. Your logic ran per request.
chrome.webRequest.onBeforeRequest.addListener(
  (details) => ({ cancel: shouldBlock(details.url) }),
  { urls: ["<all_urls>"] },
  ["blocking"]
);

// MV3. A rule Chrome evaluates.
{
  "id": 1,
  "priority": 1,
  "action": { "type": "block" },
  "condition": {
    "urlFilter": "||tracker.example.com",
    "resourceTypes": ["script", "xmlhttprequest"]
  }
}

shouldBlock() cannot run any more. If it was a simple domain check, the rewrite is mechanical. If it encoded real business logic, that logic has to be re-expressed as static rulesets shipped with the extension, or dynamic rules updated at runtime, and there are limits on how many of each you get. Some behaviour cannot be expressed as a rule at all and needs redesigning around a different mechanism.

Read only observation still works. It is specifically the "blocking" capability, and modifying requests in flight, that is gone.

3. Remotely hosted code is banned

Every line of JavaScript your extension executes must now ship inside the package and be reviewed. Fetching a script from your CDN and evaluating it is not permitted, and neither is executing arbitrary strings.

For most extensions this is a small change. For anyone who built a feature-flag or hot-patch mechanism this way, it removes an entire deployment strategy: every change now goes through store review. Teams accustomed to shipping a fix in ten minutes need to plan around review time instead.

4. No DOM in the background

A service worker has no window and no DOM. Anything that parsed HTML in the background, used a canvas to resize an image, played audio, or read from localStorage now needs an offscreen document created through the Offscreen API, with message passing between it and the worker. XMLHttpRequest is also unavailable and becomes fetch.

A small extension with a popup, a content script and no request interception is usually a few days of work plus testing. An extension whose value lives in blocking or rewriting network requests can be a genuine redesign, because the constraint is architectural rather than a matter of effort.

Six days is enough for the decision, not for the rewrite

Nobody rebuilds a non-trivial extension by Monday. What is achievable before 31 August is knowing exactly what you are about to lose and making a deliberate choice about it.

1. Establish whether you are affected. Ten minutes, using the checks above. Most people reading this are already on Manifest V3 and can stop here.
2. Find the publishing account. Before anything else. A listing whose owning Google account nobody can identify is a harder problem than a rewrite, and it does not get easier after the item disappears.
3. Decide whether the listing is worth saving. If the extension was an internal tool, the store listing may be worth nothing to you and a fresh MV3 item is fine. If it carries reviews, installs and inbound links, it is worth protecting.
4. Work out which category you are in. Does the extension intercept or modify network requests? That single answer separates a few days of work from a redesign, and you can determine it by searching the source for webRequest.
5. Tell the people who depend on it. If enterprise customers force-install your extension by ID, they need to hear it from you rather than from their fleet.

Sources

All primary, from Google:

• Manifest V2 deprecation timeline
• Manifest V3 migration checklist
• Migrate to a service worker

Day counts calculated from 25 August 2026.