📅 Published 23 April 2026

The Manifest V3 transition has been the most contentious platform change in Chrome extension history, and in 2026 it is finally unavoidable. Chrome has disabled Manifest V2 extensions for most users, Firefox has shipped its own MV3 implementation with deliberate differences from Chrome's, and extension developers must navigate a platform that nominally shares a specification but diverges in the details that matter most. Having maintained extensions through this transition, the pain points are real but manageable — if you understand where the platform differences lie.

This page covers the practical reality of Manifest V3 development in 2026: the architectural changes that affect every extension, the migration path from MV2, the cross-browser differences that require platform-specific code, and the capabilities that MV3 restricts compared to its predecessor. The page is part of the development section and connects to the browser extensions topic hub.

The architectural shift​

Manifest V3 replaces background pages with service workers, replaces the webRequest blocking API with declarativeNetRequest, and restricts remotely hosted code. Each change has a rationale (performance, security, privacy) and a cost (reduced capability, increased complexity).

Background pages → Service workers​

MV2 background pages were persistent — they loaded when the browser started and stayed in memory. MV3 service workers are event-driven and terminate after 30 seconds of inactivity (5 minutes in some cases). This means any state stored in global variables is lost when the service worker restarts.

The practical impact: if your extension maintains in-memory state (connection pools, accumulated data, real-time counters), that state must be persisted to chrome.storage and restored on each service worker activation. The trackerless magnets extension documentation on this site covers specific patterns for managing extension state across service worker lifecycles.

// MV2: State persisted in memory
let counter = 0;
chrome.runtime.onMessage.addListener((msg) => {
  counter++;
});

// MV3: State must be persisted
chrome.runtime.onMessage.addListener(async (msg) => {
  const { counter = 0 } = await chrome.storage.session.get('counter');
  await chrome.storage.session.set({ counter: counter + 1 });
});

webRequest → declarativeNetRequest​

MV2's webRequest API let extensions intercept and modify any network request programmatically. MV3's declarativeNetRequest requires extensions to declare rules ahead of time — the browser applies the rules without executing extension code for each request.

For ad blockers and privacy extensions, this is the most significant restriction. declarativeNetRequest limits the number of rules, restricts dynamic rule modification, and does not support the full range of request modifications that webRequest enabled. uBlock Origin's migration to MV3 ("uBOLite") demonstrates the capability reduction — the MV3 version is measurably less effective than the MV2 version because the declarative API cannot express all the filtering logic the original required.

For extensions that primarily need to block or redirect requests based on URL patterns, declarativeNetRequest works well and is genuinely more performant. For extensions that need to inspect or modify request/response headers dynamically, the capability gap is real.

Cross-browser differences in 2026​

Firefox's MV3 implementation diverges from Chrome's in several important ways:

webRequest remains available in Firefox MV3. Firefox chose to keep the blocking webRequest API alongside declarativeNetRequest, preserving the full capability that Chrome removed. Extensions targeting both browsers can use webRequest on Firefox and declarativeNetRequest on Chrome, but this requires platform-specific code paths.

Service worker vs. event pages. Firefox MV3 supports both service workers and event pages (non-persistent background pages). Chrome MV3 requires service workers. For simpler extensions, using an event page on Firefox avoids the service worker lifecycle complexity.

content_security_policy differences. Chrome's MV3 CSP is more restrictive than Firefox's, particularly around eval() and dynamic code execution. Extensions that generate or evaluate code at runtime need separate CSP configurations per browser.

Host permission handling. Chrome prompts users to approve host permissions at runtime. Firefox grants them at install time (matching MV2 behaviour). This affects the user experience of extensions that need broad host access.

Migration strategy​

For existing MV2 extensions, the migration path:

1. Replace the background page with a service worker. Persist all state using chrome.storage.session (ephemeral, fast) or chrome.storage.local (persistent). Handle service worker startup by restoring state.

2. Replace webRequest with declarativeNetRequest if your rules are expressible as static or dynamic declarative rules. If not, accept the capability reduction on Chrome and maintain webRequest as a Firefox-specific code path.

3. Replace remotely hosted code with bundled code. MV3 requires all executable code to be included in the extension package. If your extension loads scripts from a server, those scripts must be bundled and the extension updated via the store for changes.

4. Test service worker lifecycle extensively. The most common MV3 bugs are state loss when the service worker terminates and restarts. Test scenarios where the service worker has been idle for minutes before a user interaction triggers it.

5. Maintain MV2 as long as your user base needs it. Firefox still supports MV2 and shows no urgency to remove it. Publishing both MV2 (for Firefox) and MV3 (for Chrome) from the same codebase using a build step that generates the appropriate manifest is a practical approach.

The broader implications​

MV3's restrictions reduce the power of browser extensions, particularly for privacy and security tools. The trade-off — improved performance and reduced risk from malicious extensions — is reasonable from the browser vendor's perspective but shifts capability from users to the platform. The extensions that are most affected are precisely the ones that power users value most: sophisticated ad blockers, privacy tools, and developer utilities that need deep request inspection.

Firefox's decision to preserve webRequest in MV3 is the most significant differentiator in the 2026 browser extension landscape. For users who depend on powerful extensions, this is a concrete reason to prefer Firefox — not because of ideology, but because the platform capability is measurably greater.