Skip to main content
Avoid maintaining separate manifest files for every browser. Extension.js lets you define browser-specific values inline with prefixes, then emits only the fields that match the active target at compile time.

​
Why this matters

Browsers still differ in key manifest areas, like background configuration and vendor metadata. Prefixed fields let you keep one source manifest.json while producing browser-correct output for Chromium-family and Firefox-family targets.

​
How it works

Extension.js scans manifest keys and resolves prefixed entries for the selected browser:
  • Chromium-family targets (chrome, edge, chromium-based) resolve: chromium:, chrome:, edge:
  • Gecko-family targets (firefox, gecko-based) resolve: firefox:, gecko:
When a prefixed key matches the active target, Extension.js rewrites it to the unprefixed key in the emitted manifest.

​
For Chromium-based browsers (Chrome, Edge, …)

{
  "chromium:background": {
    "service_worker": "sw.js"
  }
}

​
For Firefox

{
  "firefox:background": {
    "scripts": ["sw.js"]
  }
}
You can also target vendor-specific variants inside the same browser family: 
{
  "chrome:action": {
    "default_title": "Chrome variant"
  },
  "edge:action": {
    "default_title": "Edge variant"
  }
}
This makes service_worker available only for Chromium-family outputs while keeping background.scripts for Firefox outputs. Supported prefix map:
PrefixIncluded for target browser
chromium:chrome, edge, chromium-based
chrome:chrome, chromium-based
edge:edge, chromium-based
firefox:firefox, gecko-based, firefox-based
gecko:firefox, gecko-based, firefox-based
This works for any manifest field at any level, including permissions, content_scripts, and background.

​
Best practices

  • Keep shared defaults unprefixed: Put common fields in regular manifest keys, then prefix only browser-specific differences.
  • Prefix only when behavior diverges: Use browser prefixes when runtime requirements differ.
  • Build per target in continuous integration (CI): Generate and verify each browser output (dist/<browser>) to catch compatibility regressions early.
  • Validate with MDN: Use MDN Web Docs to confirm support before adding browser-only settings.

​
Next steps