Will Your Edge Extension Stop Working in 2026? Microsoft’s Manifest V2 Shutdown Explained

If an Edge extension still uses Manifest V2, it is now on borrowed time for consumer users — but Microsoft has not published one universal switch-off date for every Edge installation.

Microsoft began the consumer transition away from Manifest V2 in August 2026. Warnings are appearing first, then MV2 extensions will be turned off by default for more users over the following months. Microsoft says the rollout starts in Canary, Dev, and Beta before broadening to Stable, with a goal of completing the consumer transition by the end of 2026.

Managed enterprise devices are on a different schedule: Microsoft says they are not affected by the consumer rollout, with enterprise deprecation expected to begin in early 2027.

That makes the right question less “What is the shutdown date?” and more:

Which part of the Edge MV2 timeline applies to my extension, and what must I migrate before the rollout reaches my users?

Status check — August 22, 2026. Microsoft’s current public timeline still leaves the exact date when the Edge Add-ons store will stop accepting updates to existing Manifest V2 extensions as TBD. Do not treat “end of 2026” as a guaranteed date for every individual device.

The Edge Manifest V2 timeline in one table

Microsoft’s August 7 announcement says notices are appearing on edge://extensions, Edge Add-ons product pages, and in Partner Center before extensions are disabled. It also says the rollout will be gradual rather than one browser-wide cutoff. Microsoft Edge Blog

Edge is now catching up with Chrome — but the timelines are not identical

A common mistake is to assume that because Edge and Chrome are both Chromium browsers, their Manifest V2 shutdown schedules are identical.

They are not.

Google’s current Chrome documentation says Manifest V2 was disabled for all Chrome users in July 2025, and that the remaining MV2 extensions will be removed from the Chrome Web Store on August 31, 2026. Extensions that remain installed on older Chrome 138-or-earlier systems can stay installed, but they cannot receive updates or be reinstalled from the store after removal. Chrome for Developers

Microsoft deliberately kept Edge MV2 support longer. Its consumer shutdown is only now starting in August 2026.

That creates a slightly awkward migration window:

So if a cross-browser extension still has an MV2 branch “because Edge still supports it,” that branch now has a clear retirement horizon.

How to tell whether an extension is actually at risk

The fastest test is boring but definitive: open the extension’s manifest.json.

If it contains:

{
  "manifest_version": 2
}

then the extension is part of the deprecation path.

If it already says:

{
  "manifest_version": 3
}

then this particular shutdown does not apply to it, although the code can still have MV3 compatibility bugs.

For an installed Edge extension, edge://extensions is also becoming a useful signal because Microsoft says affected users will see MV2 notices there as the rollout progresses.

The four migration areas most likely to cause real work

Changing "manifest_version": 2 to 3 is not a migration by itself. Microsoft’s migration guide calls out several structural changes that affect how extensions run. Microsoft Learn

1. Background pages become service workers

Manifest V2 extensions commonly keep a background page alive for long-running state and event handling.

Manifest V3 moves background logic to a service worker.

That changes the mental model. A service worker can be suspended between events, so code should not assume that global in-memory variables remain alive forever.

A practical audit is to search the background code for state that exists only in JavaScript memory:

• authentication/session flags;
• queues;
• timers;
• cached configuration;
• maps of active tabs;
• retry counters.

If losing that state when the worker sleeps would break the extension, move the durable part into an appropriate extension storage API and rebuild transient state when necessary.

2. Permissions are split more explicitly

MV3 separates ordinary permissions from host access using permissions and host_permissions.

That means an extension that previously placed everything in one broad permission list may need its manifest reorganised.

This is also a good moment to reduce access. If the extension only needs a small group of domains, asking for every site is harder to justify than it used to be.

3. Network interception may need redesign

Manifest V3 pushes many request-blocking use cases toward declarativeNetRequest rather than arbitrary blocking logic in webRequest listeners.

For simple filtering, this can make the extension easier for the browser to evaluate without executing extension code for every request.

For complex extensions, however, the migration can require a design change rather than a syntax change.

Microsoft notes that enterprise-managed extensions can retain blocking webRequest behaviour under enterprise policy, but that should not be treated as a general consumer workaround for staying on MV2.

4. Remotely hosted executable code is a problem

MV3 is built around the idea that executable extension code should be reviewable as part of the submitted package rather than silently replaced from a remote server after installation.

If an extension downloads JavaScript and executes it dynamically, or depends on runtime code injection from a remote source, that architecture needs scrutiny.

Remote data is not the same thing as remote executable code: loading configuration or API responses is normal. The risky pattern is treating a server as a way to ship new executable behaviour without an extension-store update.

A 20-minute MV2 risk audit

Before turning this into a multi-week migration project, a short audit can reveal whether the extension is simple or genuinely difficult to move.

Step 1: confirm the manifest version

Search for:

"manifest_version": 2

If there is no MV2 manifest in the active build, stop: this shutdown is not the immediate problem.

Step 2: find the background model

Search for:

background
persistent
scripts

Then identify what would happen if the background process disappeared and restarted between events.

Step 3: inspect privileged network logic

Search for APIs such as:

webRequest
webRequestBlocking
declarativeNetRequest

If the extension modifies or blocks requests dynamically, budget time for behaviour-level testing rather than assuming a mechanical migration.

Step 4: look for code that arrives from the network

Search for patterns such as dynamic script injection, fetched JavaScript, or server-provided code paths.

The goal is to separate ordinary remote data from executable code that should ship inside the extension package.

Step 5: map permissions

Write down exactly why each permission and host pattern exists.

This catches two problems at once: MV3 manifest restructuring and years of permission creep.

Step 6: test suspension, restart, and update behaviour

Do not only test the happy path after installing the MV3 build.

Test what happens when:

• the service worker stops and restarts;
• the browser restarts;
• the extension updates;
• a tab is restored later;
• a network request fails halfway through a task;
• a permission is denied or removed.

Those lifecycle cases are where an MV3 migration that “worked locally” often becomes unreliable in normal use.

Which teams need to move first?

A simple priority framework:

The important distinction is distribution, not company size. A tiny extension with consumer users can have less time than a large internal extension deployed only through managed enterprise policy.

Do you need a separate Edge codebase?

Usually, no.

For many extensions the practical target is one MV3 codebase with small browser-specific differences rather than maintaining an “old Edge MV2 build” indefinitely.

A useful architecture is:

shared extension code
        ↓
Manifest V3
        ↓
small compatibility layer where APIs differ
        ↓
Chrome build / Edge build / other Chromium builds

Keep separate code only where browser behaviour genuinely differs. Every permanent fork adds testing work, release coordination, and the chance that a security fix lands in one browser but not another.

What is confirmed, and what is still uncertain?

Confirmed

As of August 22, 2026:

• Microsoft has started the Edge consumer transition away from MV2.
• Affected users will receive warnings before disablement.
• The rollout begins in pre-Stable channels and broadens to Stable.
• Microsoft’s goal is to complete the consumer transition by the end of 2026.
• Managed devices are excluded from this consumer rollout.
• Enterprise deprecation is expected to begin in early 2027.
• Partner Center now shows MV2 deprecation warnings.

Still uncertain

Microsoft has not published:

• one exact date when every consumer Edge installation will stop running MV2;
• the exact Stable rollout date for every user cohort;
• the final date when Edge Add-ons will stop accepting ordinary updates to existing MV2 extensions.

Microsoft’s public timeline lists that store-update cutoff as TBD. Microsoft Learn

That uncertainty is a reason to migrate earlier, not a reason to wait for a final deadline.

What to watch next

Three signals matter more than rumours about a single “shutdown day.”

1. Stable-channel rollout notices

Microsoft says the disablement will broaden from Canary, Dev, and Beta to Stable. When Stable cohorts begin seeing the change more widely, consumer breakage becomes much more visible.

2. The Edge Add-ons update cutoff

This is the biggest missing date for developers maintaining a live MV2 listing. Microsoft still marks it TBD.

3. Enterprise policy dates

Managed devices have extra runway, but “early 2027” is close enough that internal extension teams should already be testing MV3 rather than treating enterprise policy as a permanent exemption.

Conclusion

Edge’s Manifest V2 shutdown is no longer a distant Chromium roadmap item. The consumer transition started in August 2026.

But the rollout is gradual, and Microsoft has deliberately not reduced it to one universal date. That makes the best response practical rather than panicked:

1. check manifest.json;
2. identify background-page, permission, network, and remote-code dependencies;
3. test the MV3 build under service-worker lifecycle conditions;
4. ship the migration before Stable disablement reaches the users who still depend on the extension.

If a public Edge extension is still on MV2, the useful deadline is not “whenever Microsoft finally turns it off for me.” It is before your users are the next cohort in the rollout.

Sources

Checked August 22, 2026:

• Microsoft Edge Blog — Moving the Microsoft Edge extensions ecosystem forward with Manifest Version 3
• Microsoft Learn — Timeline for migrating to Manifest V3
• Microsoft Learn — Migrate an extension from Manifest V2 to V3
• Chrome for Developers — Manifest V2 support timeline
• Chrome for Developers — Update the manifest