Guide

Rebuilding Manifest V2 extensions for Manifest V3

A practical Manifest V3 migration guide for Chrome extension developers: convert background pages to service workers, replace blocking webRequest, and pick which abandoned MV2 extensions are worth rebuilding.

Why MV2 extensions are worth rebuilding

Chrome now runs Manifest V3 only. Extensions that were never migrated stopped working or were removed from the Chrome Web Store, even when they still had large, active user bases and years of positive reviews. That leaves demand without supply: the users are still searching for a replacement, and the original product already proved the problem is real.

Rebuilding beats starting from scratch because the discovery work is done. You know the audience, the feature set that earned the ratings, and often the original source code license if the project was open source.

Step 1: pick a candidate you can actually ship

Three signals decide whether a rebuild is realistic, and they are exactly the ones scored in the Browse table:

  • Neglect — how long since the last update. An extension untouched since 2020–2024 is likely abandoned rather than mid-migration, so you are not racing the original author.
  • Demand — installs plus rating volume. High installs with very few ratings is a weak signal (often inflated or short-lived); high installs with thousands of ratings is a durable audience.
  • Complexity — how much of the extension depends on APIs that MV3 changed. Content-script and UI-heavy extensions port quickly; request-blocking and long-lived-background extensions take real redesign work.

Sort by potential, then filter by category, manifest version, and complexity to find rows that match your skills. Verify trademark exposure and current store availability before you write code.

Browse migration candidates

Step 2: the manifest itself

Set "manifest_version": 3, then split the old permissions array: hosts move into host_permissions, and everything else stays. Replace browser_action or page_action with a single action key, and swap web_accessible_resources for the object form with explicit matches. content_security_policy becomes an object with extension_pages; remote code and unsafe-eval are no longer allowed.

Step 3: background page to service worker

The biggest behavioural change. A background service worker terminates when idle, so anything held in a module-level variable disappears. Move state into chrome.storage.local or session, replace setTimeout/setInterval schedules with chrome.alarms, and register every listener synchronously at the top level so the worker can be woken by the event. There is no DOM: XMLHttpRequest, document, and localStorage are unavailable, so use fetch and the storage APIs.

Step 4: blocking webRequest to declarativeNetRequest

This is where most abandoned blockers, privacy tools, and ad filters died. Blocking chrome.webRequest is gone for regular extensions. Rewrite rules as declarativeNetRequest static rulesets in JSON plus dynamic or session rules added at runtime. Observation-only webRequest listeners still work, so logging and analytics features usually survive unchanged.

Rule counts are capped, so consolidate patterns and use regexFilter sparingly. If your feature genuinely cannot be expressed declaratively, redesign it as a content-script intervention instead of trying to reconstruct the old interception model.

Step 5: scripting, promises, and remote code

chrome.tabs.executeScript and insertCSS become chrome.scripting.executeScript and insertCSS with a target object and the scripting permission. Most chrome.* APIs now return promises, which lets you drop nested callbacks. Any feature that loaded a remote script must ship that logic inside the package or move it behind an API call you control.

Step 6: commercial strategy after the port

A straight one-to-one port rarely wins on its own. The rebuild is your chance to fix the top complaints in the original reviews, add sync or a paid tier the original never had, and publish under a clearly distinct name and icon so you are not trading on someone else’s brand.

Practical sequencing: ship a small MV3 version that covers the two or three features most reviews mention, publish it, then use the incoming reviews to decide what to build next. Where the original was open source, respect its license — keep attribution and the same license terms when the code is copyleft.

Where to go next

See how the opportunity score is built for the exact inputs behind neglect, demand, and complexity, or check the FAQ for data-source caveats. Chrome’s own migration documentation is the authoritative reference for individual API changes.