Skip to content
Dware

Browser extensions

Hire Firefox extension developers to build, port and sign your add-on

Our Firefox extension developers build new add-ons and port existing Chrome extensions to Firefox, then take them through signing and review on addons.mozilla.org. We handle the browser differences, the source code rules and the release process, on desktop and on Firefox for Android.

  • Chrome to Firefox ports that respect the real API differences
  • Reproducible builds and source packages AMO reviewers accept
  • Listed on AMO or signed for self-distribution

Overview

What Firefox extension developers do that Chrome developers often miss

Firefox add-ons are built with the WebExtensions API, the same family of APIs Chrome uses. That makes many people think a Chrome extension will simply run in Firefox. Often it nearly does, but the last ten percent is where projects stall: a background script that relies on a Chrome-only API, a manifest key Firefox reads differently, a missing add-on ID, or a bundled build that AMO reviewers cannot reproduce. Firefox extension developers know these gaps and plan for them from the start.

Firefox has its own model in several places. It offers the promise-based browser namespace, keeps supporting blocking webRequest for content filtering and privacy tools, and runs Manifest V3 background code as non-persistent background scripts with DOM access rather than relying only on a service worker. It has a sidebar_action instead of Chrome's side panel API, container tabs and other Firefox-only APIs, and a different way of granting host permissions that users can change from the add-ons menu at any time.

Every add-on must be signed by Mozilla before release Firefox will install it. You can list it publicly on addons.mozilla.org, known as AMO, or sign it as unlisted and distribute it yourself. Either way it passes automated validation, and listed add-ons can be picked for human review. If your code is minified, bundled or transpiled, Mozilla requires the original source and exact build steps so a reviewer can rebuild the same files. Teams that skip this step get stuck in review.

When you hire Firefox extension developers from Dware, you get senior engineers who treat Firefox as a first-class target, not an afterthought. They write one shared codebase where possible, isolate browser-specific code cleanly, and give you a release process that produces signed Firefox builds alongside your Chrome ones.

What we build

Firefox add-on development services

We cover the full life of a Firefox add-on, from a new idea or an existing Chrome codebase to a signed, listed and maintained release.

  • Porting Chrome extensions to Firefox

    We audit your Chrome extension for unsupported APIs and manifest keys, then adapt it so one codebase builds for both browsers. Browser-specific code goes behind small adapters instead of if-statements scattered everywhere.

  • New Firefox add-on development

    We build add-ons designed for Firefox from the start, using the browser namespace, Firefox-only APIs like container tabs where they help, and a sidebar where it suits the product.

  • AMO listing, signing and review

    We prepare the AMO listing, privacy policy and data collection declarations, upload signed versions and answer reviewer questions. If a version is rejected, we fix the cause and resubmit.

  • Source code packages for minified builds

    We make your build reproducible and write the README that tells reviewers exactly which commands rebuild the submitted files. This is often the single change that unblocks a stuck review.

  • Self-distributed and enterprise add-ons

    We sign add-ons as unlisted, host them on your own site with an update manifest, and help IT teams deploy them with Firefox enterprise policies.

  • Privacy and content filtering tools

    We build blockers, privacy tools and security add-ons that use Firefox's webRequest and DNS APIs, with clear permission prompts and careful handling of browsing data.

  • Firefox for Android support

    We adapt popups and options pages for small screens, avoid APIs that Android does not support and test on real devices before marking the add-on as Android compatible on AMO.

Our process

How our Firefox extension developers build and ship your add-on

Whether we start from a blank page or an existing Chrome extension, the process is the same. Each step is specific to Firefox and ends with something you can check.

  1. 1

    Discovery and compatibility audit

    We learn what the add-on must do and who uses it. If you already have a Chrome extension, we run it through web-ext lint and read the code to list every API and manifest key that behaves differently in Firefox. We check MDN's browser compatibility data for each one and note which features need a Firefox alternative. You get a short report that shows what ports cleanly, what needs work and what Firefox does better.

    What you get

    • Compatibility report
    • List of Firefox-specific changes
    • Free, fixed quote
  2. 2

    Architecture for one codebase, two browsers

    We design a shared core with thin browser adapters. We use the browser namespace with promises in shared code, and webextension-polyfill or a small wrapper where Chrome needs it. The manifest is generated per browser at build time, so Firefox gets its browser_specific_settings with a fixed add-on ID and its background scripts, while Chrome gets its service worker. We decide early whether the add-on will be listed on AMO or self-distributed, because that changes update handling.

    What you get

    • Shared core and adapter plan
    • Per-browser manifest templates
    • Distribution decision
  3. 3

    Reproducible build setup

    Mozilla reviewers must be able to rebuild your minified or bundled code and get the same output. We pin Node and package versions with a lockfile, avoid build steps that depend on the machine or the time, and write a plain build script with one command. We set up web-ext run for local testing with live reload, and keep third-party libraries as unmodified copies that reviewers can match to their official sources.

    What you get

    • Pinned, one-command build
    • Reviewer build README
    • Local web-ext setup
  4. 4

    Build and port in small steps

    We work feature by feature and share a new build each week, loaded through about:debugging so you can try it in your own Firefox. Where Chrome code used offscreen documents, we use Firefox's background page DOM instead. Where the product needs a panel, we use sidebar_action. We handle host permissions that users may not have granted yet, with a clear prompt that asks at the right moment. Every pull request is reviewed by a second senior engineer.

    What you get

    • Weekly test builds
    • Reviewed pull requests
    • Progress updates
  5. 5

    Testing on desktop and Android

    We unit test shared logic and run end-to-end tests that launch Firefox with the add-on installed. We test on Firefox release, Beta and Nightly, plus Firefox ESR if your users are in companies. For Android we install the add-on on real devices and in the emulator with web-ext run, and check every popup and options page on a small screen. We also test with permissions revoked, because Firefox users can remove host access at any time.

    What you get

    • Automated test suite
    • Desktop and Android test results
    • Permission edge case checks
  6. 6

    Signing, AMO submission and review

    We create API credentials on your AMO developer account and sign builds from CI with web-ext sign. For listed add-ons we write the listing, add screenshots and fill in the data collection and privacy details. When the package contains minified code, we upload the source archive with the build README. If a reviewer asks a question or rejects the version, we answer quickly with the exact fix. For self-distribution we sign as unlisted and publish the update manifest on your server.

    What you get

    • Signed add-on file
    • AMO listing or update manifest
    • Source archive for reviewers
  7. 7

    Release, maintenance and Firefox updates

    Firefox ships a new release about every four weeks. We test upcoming versions on Beta and Nightly so changes do not surprise your users. We monitor errors and AMO reviews, release fixes through the same signed pipeline, and keep the Chrome and Firefox builds in step. You can keep us on for support or take over with full documentation.

    What you get

    • Release checklist
    • Monitoring and support plan
    • Handover docs on request

Want this process for your project? Tell us what you're building and get a free, fixed quote.

Get a free quote

Technical expertise

Firefox add-on expertise that gets you through review

These are the areas where Firefox ports and new add-ons most often go wrong, and how our developers deal with them.

Chrome and Firefox API differences

Most chrome.* calls work in Firefox, but not all of them. Firefox does not support some Chrome-only APIs, uses sidebar_action rather than the side panel API, and runs background code as event-driven scripts. We map each difference to a Firefox approach and keep the branches in one place so the codebase stays readable.

Source code submission rules

If your add-on contains code that was minified, concatenated, transpiled or generated, Mozilla asks for the original source and step-by-step build instructions. The reviewer's build must match the files you uploaded. We make builds deterministic and test the source archive on a clean machine before we submit it.

Signing and distribution choices

Listed add-ons appear on addons.mozilla.org, get automatic updates and can be chosen for manual review. Unlisted add-ons are signed after automated checks and you host them yourself with an update_url. We help you pick the right channel and set up the update flow so users always get new versions.

No remote code and clear data use

Mozilla's add-on policies forbid loading and running code from outside the package, and require honest disclosure of any data the add-on collects or sends. We keep all logic in the package, ask for consent where the policies require it and write a privacy policy that matches what the code really does.

Firefox for Android

Firefox for Android supports a growing set of extensions, but some APIs are missing and the screen is small. We check each API against Android support, design popups that work on a phone and only mark the add-on as Android compatible once it passes real device tests.

Skills and tools our Firefox extension developers use

Firefox platform and APIs

  • WebExtensions API
  • browser namespace with promises
  • Manifest V2 and V3
  • webRequest and declarativeNetRequest
  • sidebar_action
  • contextualIdentities (containers)
  • browser.storage and alarms

Languages and frameworks

  • TypeScript
  • JavaScript
  • React
  • Svelte
  • Preact
  • CSS

Build and cross-browser tooling

  • web-ext CLI
  • WXT
  • webextension-polyfill
  • Vite
  • Rollup
  • ESLint

Testing, signing and release

  • Playwright and Selenium
  • Vitest
  • Firefox Nightly and Beta
  • Android emulator and devices
  • AMO signing API
  • GitHub Actions

Why Dware

Why hire Firefox extension developers from Dware

Cross-browser by design

We build one codebase that produces Chrome and Firefox builds, so new features reach both audiences without double work.

We know AMO review

Our developers prepare reproducible builds, clear source packages and honest data disclosures, which keeps review moving.

Senior engineers only

Every developer is vetted for extension experience, and a second senior engineer reviews every change before it is merged.

Your accounts, your code

Add-ons are signed and listed under your AMO account and the code lives in your repository. You own all code and IP, with an NDA on request.

Flexible and low risk

We match you with a developer within 48 hours, start with a two-week risk-free trial and let you scale the team up or down monthly.

Ways to work with us

Ways to hire Firefox extension developers

Hire one developer, add a whole team, or hand us a fixed-scope project. Tell us what you need and we'll send a free, fixed quote, usually within one business day.

Dedicated developer

Most popular

A senior engineer who works only on your product, full-time or part-time.

  • Joins your Slack, standups and Git
  • Same developer every day
  • Scale up or down monthly

Team extension

Two or more developers, plus QA or a tech lead, added to your team.

  • Matched to your stack and time zone
  • One point of contact
  • Add or remove people any month

Fixed-scope project

A clear scope, timeline and fixed quote. Ideal for MVPs, apps and fixes.

  • Free, fixed quote before we start
  • Milestones you approve
  • Support after launch

FAQ

Hire Firefox extension developers: frequently asked questions

Can you port my Chrome extension to Firefox?

Yes, and it is one of the most common jobs we do. We first run a compatibility audit to see which APIs and manifest keys differ, then build a shared codebase that outputs both a Chrome and a Firefox package. Simple extensions often port quickly. Extensions that rely on Chrome-only APIs, such as offscreen documents or the side panel, need a Firefox alternative, and we explain each one before we start.

How much does it cost to hire Firefox extension developers?

The main drivers are whether we port an existing extension or build a new one, how many Chrome-only features need a Firefox alternative, whether you need Android support, and how much backend work is involved. Review preparation and reproducible builds are part of the scope. After a short call we give you a free, fixed quote so you know the full cost before we begin.

Does every Firefox add-on need to be signed?

Yes. Release and Beta versions of Firefox only install add-ons signed by Mozilla. Developer Edition and Nightly can load unsigned add-ons for testing, and anyone can load a temporary add-on through about:debugging, but your users need a signed file. We sign through your AMO account, either as a listed add-on on addons.mozilla.org or as an unlisted one you host yourself.

Why do AMO reviewers ask for my source code?

Reviewers need to read the code that runs in Firefox. If your package contains minified, bundled or transpiled files, they cannot review it properly, so Mozilla asks for the original source and exact build instructions. They then rebuild it and compare the result to your upload. If the files do not match, review stalls. We set up a reproducible build and a clear README so this goes smoothly.

Should we list on addons.mozilla.org or self-distribute?

Listing on AMO gives you a public page, search traffic inside Firefox and automatic updates for users. Self-distribution suits internal tools, beta programs and enterprise customers who manage Firefox with policies. Self-distributed add-ons are still signed by Mozilla, but you host the file and an update manifest yourself. Many teams use both: a listed version for the public and an unlisted one for testers.

Does Firefox support Manifest V3?

Yes, Firefox supports both Manifest V2 and Manifest V3. Its Manifest V3 implementation differs from Chrome's in a few ways, such as how background code runs and how host permissions are granted, and Mozilla has said it will keep supporting blocking webRequest. We choose the manifest version that fits your add-on and keep the Chrome and Firefox builds consistent.

Will my add-on work on Firefox for Android?

It can. Firefox for Android supports a wide range of extensions, but not every desktop API is available and the interface needs to work on a phone. We check your APIs against Android support, adapt the popup and options pages and test on real devices. Once it passes, we mark the add-on as compatible with Android on AMO.

How long does AMO review take?

Automated validation usually finishes within minutes, and many listed add-ons are available soon after. Some versions are picked for manual review, which can take longer, especially when the package has large bundled files or sensitive permissions. Clean, readable code and a working source archive are the best way to keep review short, and we plan time for it in every release.

Who owns the add-on and the AMO listing?

You do. The add-on is listed and signed under your own AMO developer account, and the code lives in your repository from the first commit. All code and IP are yours, and we can sign an NDA before we see any of your existing code.

Bring your extension to Firefox

Tell us about your add-on idea, or send us your Chrome extension and we will tell you what it takes to run it in Firefox. Book a free consultation and get a fixed quote, with a senior Firefox extension developer matched within 48 hours.

Email hello@dware.devFree quote · NDA on request