• Skip to main content
  • Select language
  • Skip to search
MDN Web Docs
  • Technologies
    • HTML
    • CSS
    • JavaScript
    • Graphics
    • HTTP
    • APIs / DOM
    • WebExtensions
    • MathML
  • References & Guides
    • Learn web development
    • Tutorials
    • References
    • Developer Guides
    • Accessibility
    • Game development
    • ...more docs
Add-ons
  1. MDN
  2. Mozilla
  3. Add-ons
  4. Signing and distributing your add-on

Signing and distributing your add-on

In This Article
  1. Signing your add-on
    1. Signing API
  2. Submitting to AMO
    1. Self-distributed (unlisted) versions
    2. Listed versions
      1. Beta versions
  3. Ownership
  4. Code disputes

Once you have a first build of your add-on, you'll want to distribute it so others can give it a try. Whether you are distributing your add-on publicly or privately, through addons.mozilla.org (AMO) or elsewhere, you'll want to have your add-on package signed.

Signing your add-on

Starting with Firefox 43, there are some restrictions in place for add-on distribution. Most add-ons that support Firefox need to be signed by Mozilla in order for them to be installable in release and beta versions of Firefox. Note that this only applies to add-on types 2 and 32; other add-on types like themes and language packs don't require signing. Add-ons that only support other applications like Thunderbird and SeaMonkey are also excluded. Unsigned add-ons can still be installed in Developer Edition, Nightly, and ESR versions of Firefox, after toggling the xpinstall.signatures.required preference in about:config.

Only Mozilla can sign your add-on so that Firefox will install it by default. Add-ons are signed by submitting them to AMO or using the API and passing either an automated or manual code review. Note that you are not required to list or distribute your add-on through AMO. If you are distributing the add-on on your own, you can choose that option and AMO will only serve as the way to get your package signed.

Signing API

If you choose, you can sign your XPI files using the addons.mozilla.org signing API. All add-ons uploaded to AMO which pass review are automatically signed. Signing your add-on prior to uploading to AMO is not required.

If your add-on is an SDK add-on then use the jpm tool, the jpm sign command will work with the API to sign your add-on.

If your extension uses WebExtension APIs then use the web-ext tool, the web-ext sign command will work with the API to sign your extension.

Submitting to AMO

New add-ons are uploaded to AMO through this submission form. The first step is to read through and accept our Developer Agreement. A tutorial is available to guide you through the submission process.

Next, you'll need to decide if you want to distribute and list your add-on file through AMO or not. Here are some things you should consider to make this decision:

  • AMO is a very popular distribution platform, with millions of monthly visitors and installations. It is integrated into the Firefox Add-ons Manager, allowing easy installation of published AMO add-ons directly from the Firefox UI.
  • All add-ons listed on AMO may be subject to code review and testing by a team of employees and volunteers. In some cases, an add-on may require a review before it can be listed. In these cases, review times can range between a few hours to a number of weeks depending on an add-on’s complexity and other factors.
  • Self-distributed add-on files are automatically reviewed and signed. The add-ons review team may, from time to time, perform a manual review of your signed add-ons and give you feedback about them.
  • When you make updates to your add-on to add features or fix bugs, you'll probably want any previously installed versions of the add-on to automatically be updated to the new version.
    • For versions hosted on AMO, all you have to do is upload the new version: Host applications (e.g. Firefox) default to checking AMO for new versions of add-ons.
    • For versions that aren't hosted on AMO, you need to tell the host application (e.g. Firefox) where it can find new versions. To do this, you need to include a URL in the add-on's manifest: update_link for WebExtensions and updateURL for legacy add-ons. The host application will go there to get information about updates. If you're using the Add-on SDK, see Supporting updates for self-hosted add-ons. Self-distributed add-ons that don't have an update URL defined in their manifest will check AMO for updates, and will be updated to a listed version if available.

Self-distributed (unlisted) versions

After accepting the Developer Agreement, choose the platforms your add-on supports and upload your add-on file. The file will be scanned by an automatic code validator which will show a number of warnings or errors, depending on what it detects. If no errors are found in your add-on package, your add-on management page will be created and your file will be immediately signed. You'll receive an email with instructions on how to download the signed file.

All new versions of your add-ons will also need to be signed. Once your first version has been submitted, you can upload new versions in the developer page for your add-on.  The signing process is the same for all self-distributed versions.

Listed versions

After accepting the Developer Agreement, choose the platforms your add-on supports and upload your add-on file. The file will be scanned by an automatic code validator which will show a number of warnings or errors depending on what it detects. Errors only show up for listed add-ons if there's something wrong in the package that needs to be fixed before it can be accepted. Warnings can vary in importance and severity; you should read through all of them carefully and see if there's anything you can fix in your add-on in order to avoid them showing up. Your add-on does not need to have no warnings generated by the automatic code validator in order to pass review, but they are areas of your add-on which you should check and possibly rewrite. You should not obfuscate your code to bypass validation warnings. That practice can lead to your add-on being rejected and potentially blacklisted.

Once you finish your listed add-on submission, it may be placed in a review queue, where a member of our review team will give it a look. This can take between a couple of hours to a number of weeks, depending on your add-on's complexity and other factors. Once your add-on passes review, the file is signed and published on AMO.

Beta versions

Beta channels are only available for listed add-ons that aren't marked as experimental.

To create a beta channel, upload a file with a unique version string that contains any of the following strings: a,b,alpha,beta,pre,rc, with an optional number at the end. This text must come at the end of the version string. If you understand RegEx format, here's what we look for in the version number: "(a|alpha|b|beta|pre|rc)\d*$".

When a file meeting this version number criteria is uploaded to AMO, it will automatically be detected as a beta version. Users of your add-on who have chosen to download beta versions will automatically be served the newest beta updates. Beta versions are treated like unlisted add-on versions, in that they will be accepted and signed immediately, if they pass automatic validation.  They also cannot be side-loaded, and must not be pushed as updates to side-loaded versions if you're also using these versions outside of AMO.

While we call these "Beta versions", you can use this channel for nightlies, or alphas, or prerelease versions, as you wish. Please note that there is only one channel for this purpose and all of your users on this channel will receive the latest add-ons submitted. For instance, if you upload 1.0beta1 to the release channel and then upload 1.1alpha1, all users of 1.0beta1 will be offered an upgrade to 1.1alpha1. Updates are pushed by submission date and not version number, so users will always get the most recent channel update regardless of any kind of alphabetical sorting.

Ownership

Add-ons can have multiple users with permission to update and manage the listing. Existing authors of an add-on can transfer ownership and add additional developers to an add-on's listing through the Developer Tools provided. No interaction with Mozilla representatives is necessary for a transfer of ownership.

Code disputes

Many add-ons allow their source code to be openly viewed. This does not mean that the source code is open source or available for use in another add-on. The original author of an add-on retains copyright of their work unless otherwise noted in the add-on's license.

In the event that we're notified of a copyright or license infringement, we will take steps to address the situation per the DMCA, which may include taking down the add-on listing. Details about this process and how to report trademark or licensing issues can be found here.

If you are unsure of the current copyright status of an add-on's source code, you must contact the original author and receive explicit permission before using the source code.

Document Tags and Contributors

 Contributors to this page: andrewtruongmoz, Jorge.villalobos, Makyen, AnnetteRivers, wbamberg, FKasa, Alien426, andymckay-github, V@no, eviljeff, Noitidart, mconnormoz, hasangol, Cikgu77, 01787500664, Macarte, kumar303, SphinxKnight, tedmcox, iwanrezpect
 Last updated by: andrewtruongmoz, Jul 14, 2017, 2:36:10 PM
See also
  1. WebExtensions
  2. Getting started
    1. What are WebExtensions?
    2. Your first WebExtension
    3. Your second WebExtension
    4. Anatomy of a WebExtension
    5. Example WebExtensions
  3. How to
    1. Intercept HTTP requests
    2. Modify a web page
    3. Add a button to the toolbar
    4. Implement a settings page
  4. User interface
    1. Introduction
    2. Toolbar button
    3. Address bar button
    4. Sidebar
    5. Context menu items
    6. Options page
    7. Bundled web pages
    8. Notifications
    9. Address bar suggestions
    10. Developer tools panels
  5. Concepts
    1. Using the JavaScript APIs
    2. Content scripts
    3. Match patterns
    4. Internationalization
    5. Content Security Policy
    6. Native messaging
  6. Porting
    1. Porting a Google Chrome extension
    2. Porting a legacy Firefox add-on
    3. Embedded WebExtensions
    4. Comparison with the Add-on SDK
    5. Comparison with XUL/XPCOM extensions
    6. Chrome incompatibilities
    7. Differences between desktop and Android
  7. Firefox workflow
    1. Temporary Installation in Firefox
    2. Debugging
    3. Developing for Firefox for Android
    4. Getting started with web-ext
    5. web-ext command reference
    6. WebExtensions and the Add-on ID
    7. Publishing your WebExtension
  8. JavaScript APIs
    1. Browser support for JavaScript APIs
    2. alarms
    3. bookmarks
    4. browserAction
    5. browsingData
    6. commands
    7. contextMenus
    8. contextualIdentities
    9. cookies
    10. devtools.inspectedWindow
    11. devtools.network
    12. devtools.panels
    13. downloads
    14. events
    15. extension
    16. extensionTypes
    17. history
    18. i18n
    19. identity
    20. idle
    21. management
    22. notifications
    23. omnibox
    24. pageAction
    25. permissions
    26. privacy
    27. proxy
    28. runtime
    29. sessions
    30. sidebarAction
    31. storage
    32. tabs
    33. topSites
    34. types
    35. webNavigation
    36. webRequest
    37. windows
  9. Manifest keys
    1. applications
    2. author
    3. background
    4. browser_action
    5. chrome_settings_overrides
    6. chrome_url_overrides
    7. commands
    8. content_scripts
    9. content_security_policy
    10. default_locale
    11. description
    12. developer
    13. devtools_page
    14. homepage_url
    15. icons
    16. incognito
    17. manifest_version
    18. name
    19. omnibox
    20. optional_permissions
    21. options_ui
    22. page_action
    23. permissions
    24. protocol_handlers
    25. short_name
    26. sidebar_action
    27. version
    28. web_accessible_resources
  10. Themes
  11. Publishing add-ons
  12. Guides
    1. Signing and distribution overview
    2. Submit an add-on
    3. Creating an appealing listing
    4. Review policies
    5. Developer agreement
    6. Featured add-ons
    7. Contact addons.mozilla.org
  13. Community and support
  14. Channels
    1. Add-ons blog
    2. Add-on forums
    3. Stack Overflow
    4. Development newsgroup
    5. IRC Channel
  15. Legacy add-ons
  16. Legacy technologies
    1. Add-on SDK
    2. Legacy Firefox for Android
    3. Bootstrapped extensions
    4. Overlay extensions