Firefox Extension Development in 2026: Build, Port, Publish

Most browser extension guides are written for Chrome. Firefox runs the same WebExtensions APIs, so a lot of that advice carries over, but not all of it. If you want an extension that works in Firefox, or you want to bring an existing Chrome extension to Firefox users, the differences decide how much work it is.

This guide covers Firefox extension development in 2026: how Firefox handles Manifest V3, what changes when you port from Chrome, how to test, and what happens when you submit to addons.mozilla.org (AMO).

Firefox vs Chrome Extensions: What Is the Same

Both browsers use the WebExtensions model. A Firefox extension is still a folder with a manifest.json, background logic, content scripts, and optional popup or options pages. The core APIs for tabs, storage, messaging, context menus, alarms and scripting exist in both, and Firefox also accepts the chrome.* namespace for compatibility. In practice, a well-structured Chrome extension often needs only a handful of changes to run in Firefox.

What Is Different in Firefox Manifest V3

Firefox supports Manifest V3, but it made a few different choices from Chrome. These are the ones that matter most when you build or port an extension:

Background scripts instead of a service worker

This is the change that breaks most ports. In Firefox you declare background scripts, which load as an event page. Code written for a service worker usually works, but anything that assumes the service worker environment (for example self.registration or worker-only globals) needs a small rewrite. A common approach is to keep the background code environment-neutral and use a build step that writes the right background key for each browser.

Host permissions the user controls

In Firefox, users can decide which sites an extension may access. Your extension should check whether it has the permission it needs, ask for it with permissions.request() from a user action, and show a clear message when it is missing instead of failing silently.

Data collection declarations

Mozilla now asks extensions to declare the personal data they collect in the manifest, so Firefox can show it to the user and ask for consent. Check the current AMO policies before you submit, because this area has been changing.

How to Port a Chrome Extension to Firefox

1. Audit the manifest. Add browser_specific_settings.gecko.id, replace background.service_worker with background.scripts for the Firefox build, and remove keys Firefox does not support.
2. Search for Chrome-only APIs. Look for APIs such as chrome.offscreen or chrome.sidePanel; Firefox has its own equivalents for some (for example sidebar_action) and none for others.
3. Normalise the namespace. Use browser.* with promises, or a small wrapper, so the same code runs in both browsers.
4. Handle permissions. Add checks for host permissions the user has not granted.
5. Test every feature in Firefox, including Firefox for Android if you want mobile users.
6. Keep one codebase. A build step that outputs a Chrome package and a Firefox package from the same source is far easier to maintain than two forks.

Testing a Firefox Extension

Mozilla's web-ext command-line tool runs your extension in a clean Firefox profile, reloads it as you edit, lints the manifest and code, and builds the final package. You can also load an extension temporarily from about:debugging. For Firefox for Android, web-ext can run the extension on a connected device.

Publishing on addons.mozilla.org

Every Firefox extension must be signed by Mozilla before it can be installed in release versions of Firefox. You can list it publicly on AMO, or sign it for self-distribution. For a listed extension, expect to provide:

• A clear description, screenshots and a privacy policy if you handle user data
• Accurate data collection declarations
• Source code if your package is minified, bundled or generated, with build instructions, so reviewers can reproduce it

Reviews look closely at remote code, broad permissions and unexplained data collection. Keeping permissions narrow and code readable is the easiest way through.

How Long Does It Take?

A small extension written with cross-browser support from day one costs little extra to ship on Firefox. Porting a large Chrome extension that relies on service-worker-only code or Chrome-only APIs takes longer, because those parts need redesigning, not just renaming. An audit of the existing code is the quickest way to get a realistic estimate. Our guide to Chrome extension development cost and timeline explains what drives the effort.

Frequently Asked Questions

Can one extension work in Chrome, Edge and Firefox?

Yes. Chrome and Edge share a base, and Firefox runs the same WebExtensions APIs with the differences above. Most teams keep one codebase and build a separate package for each store.

Does Firefox support Manifest V3?

Yes. Firefox supports Manifest V3, with background scripts instead of service workers and with blocking webRequest still available.

Do Firefox extensions work on Android?

Yes, Firefox for Android can run extensions. Some APIs are not available on mobile, so test there if Android users matter to you.

Is publishing on addons.mozilla.org free?

Yes. There is no fee to list or sign an extension on AMO.

Need a Firefox version of your extension, or a new extension for Chrome, Edge and Firefox? See our browser extension development services, or tell us about your project. If you are starting from scratch, our Manifest V3 extension tutorial is a good first read.