Manifest V2 to V3 Converter (MV2 to MV3)

Google phased Manifest V2 out over four years. Today no version of Chrome runs it:

Existing installs on Chrome 138 or earlier keep running, but they can't be updated or reinstalled. Source: Chrome's Manifest V2 support timeline.

It applies every manifest change in Chrome's migration guide:

When your background page ran several scripts, the converter writes a service-worker.js that loads them in order with importScripts(). Paste the result into the Manifest V3 validator, or compare versions in the JSON diff.

The manifest is the easy part. A service worker isn't a background page: it has no DOM, starts when an event arrives and stops when idle. The checklist covers each change, with links to Chrome's guide:

• Move DOM and window work to an offscreen document.
• Replace localStorage with chrome.storage, and global variables with stored state.
• Register every listener at the top level, not inside callbacks.
• Replace setTimeout and setInterval with chrome.alarms, and XMLHttpRequest with fetch().
• Rename APIs: chrome.extension.getURL becomes chrome.runtime.getURL, and tabs.executeScript becomes scripting.executeScript.

// Manifest V2
chrome.tabs.executeScript(tabId, { file: "content.js" });

// Manifest V3: add the "scripting" permission
chrome.scripting.executeScript({ target: { tabId }, files: ["content.js"] });

The declarativeNetRequest API. Instead of a listener that decides about each request, you describe rules and Chrome applies them, without your code seeing the traffic. Blocking needs only the declarativeNetRequest permission, which shows "Block content on any page".

[
  {
    "id": 1,
    "priority": 1,
    "action": { "type": "block" },
    "condition": { "urlFilter": "||example.com", "resourceTypes": ["main_frame"] }
  }
]

Only extensions installed by enterprise policy can still use webRequestBlocking in Manifest V3. See replacing blocking web requests.

No. All logic must ship in the package: no scripts from your server or a CDN, no eval() or new Function() on fetched strings. The extension_pages policy may only allow 'self', 'none', 'wasm-unsafe-eval' and, while unpacked, localhost. The converter removes everything else and lists what it took out.

You can still fetch data and configuration, and sandboxed pages may evaluate code. The Chrome Web Store allows remote logic only through the Debugger and User Scripts APIs. Bundle libraries you used to load from a CDN. Once your extension is ready, it needs a privacy policy if it handles user data: the privacy policy generator for Chrome extensions covers the Chrome Web Store's requirements.