Support for extensions using XUL/XPCOM or the Add-on SDK was removed in Firefox 57, released November 2017. As there is no supported version of Firefox enabling these technologies, this page will be removed by December 2020.

Add-ons using the techniques described in this document are considered a legacy technology in Firefox. Don't use these techniques to develop new add-ons. Use WebExtensions instead. If you maintain an add-on which uses the techniques described here, consider migrating it to use WebExtensions.

Starting from Firefox 53, no new legacy add-ons will be accepted on addons.mozilla.org (AMO) for desktop Firefox and Firefox for Android.

Starting from Firefox 57, only extensions developed using WebExtensions APIs will be supported on Desktop Firefox and Firefox for Android.

Even before Firefox 57, changes coming up in the Firefox platform will break many legacy extensions. These changes include multiprocess Firefox (e10s), sandboxing, and multiple content processes. Legacy extensions that are affected by these changes should migrate to use WebExtensions APIs if they can. See the "Compatibility Milestones" document for more information.

A wiki page containing resources, migration paths, office hours, and more, is available to help developers transition to the new technologies.

Introduction

An Install Manifest is the file an Add-on Manager-enabled XUL application (e.g. Firefox or Thunderbird) uses to determine information about an add-on as it is being installed. It contains metadata identifying the add-on, providing information about who created it, where more information can be found about it, which versions of what applications it is compatible with, how it should be updated, and so on.

The format of the Install Manifest is RDF/XML.

The file must be called install.rdf and live at the top level of an add-on's XPI file.

Layout

The basic layout of an Install Manifest is like so:

<?xml version="1.0" encoding="UTF-8"?>

<RDF xmlns="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
     xmlns:em="http://www.mozilla.org/2004/em-rdf#">
  <Description about="urn:mozilla:install-manifest">
    <!-- properties -->
  </Description>
</RDF>

Some properties are required, some are optional. Some have simple string values, some are complex resources.

Required Property Reference

Your Install Manifest must specify these properties correctly otherwise your add-on may not install.

id

The ID of the extension, which must be one of the following:

The latter format is significantly easier to generate and manipulate. Firefox 1.5 has checking to ensure that your id falls into one format or the other and will refuse to install add-ons that have malformed ids. You should not use a real email address for your id, however, as it might attract spam.

Note: The id property is optional in a WebExtension. If you do not provide an id, the Add-ons site will generate an id for your add-on automatically.

Examples

<em:id>extensionname@example.org</em:id>

<em:id>{daf44bf7-a45e-4450-979c-91cf07434c3d}</em:id>

name

The name of the add-on; intended for display in the UI.

Examples

<em:name>My Extension</em:name>

targetApplication

An object specifying an application targeted by this add-on. This means that the add-on will work with the application identified by the id property (<em:id>) specified (for a comprehensive list of application IDs and valid min/maxVersions for them see Valid application versions for add-on developers), from the minimum version (<em:minVersion>) up to and including the maximum version (<em:maxVersion>). However, while <em:maxVersion> is a required property, it is ignored unless you also set <em:strictCompatibility> in the main <Description> of your install.rdf (i.e. not in <em:targetApplication>). These version strings are formatted in the same fashion as the version property and will be compared to the application version; this allows the extension author to specify which versions of Firefox an extension has been tested with.

id, minVersion, and maxVersion are all required.

Note: Extensions compatible with Firefox 3.5 should specify a maxVersion of 3.5.*, so that they are automatically compatible with security and stability updates. For Firefox 3.0, a maxVersion of 3.0.* should be used. Extensions compatible only with Firefox or Thunderbird 2 should specify a maxVersion of 2.0.0.*.

The Install Manifest must specify at least one of these objects, and may specify more if the add-on targets multiple applications that support the Add-on Manager (e.g. Firefox and Thunderbird).

Examples

<em:targetApplication>
  <Description>
    <em:id>{ec8030f7-c20a-464f-9b0e-13a3a9e97384}</em:id> <!--Firefox-->
    <em:minVersion>1.5</em:minVersion>
    <em:maxVersion>3.0.*</em:maxVersion>
  </Description>
</em:targetApplication>

Gecko 1.9 based applications allow you to use the special targetApplication id toolkit@mozilla.org to say that the add-on is compatible with any toolkit app with a toolkit version matching the minVersion and maxVersion.

type

An integer value representing the type of add-on.

2 Extensions
4 Themes
8 Locale
32 Multiple Item Package
64 Spell check dictionary
128 Telemetry Experiment
256 WebExtension Experiment

Examples

<em:type>2</em:type>

This property was added for Firefox 1.5, and is only required for add-on types other than Extensions and Themes.

Firefox 2 and previous supported a value of 16 to represent plug-ins. In Firefox 3 this has been removed.

version

A version string identifying the version of the add-on being supplied.

For Firefox/Thunderbird 1.0, the format must conform to the rules specified in Extension Versioning, Update and Compatibility. For Firefox/Thunderbird 1.5, see Toolkit version format.

Examples

<em:version>2.0</em:version>

<em:version>1.0.2</em:version>

<em:version>0.4.1.2005090112</em:version>

Firefox 1.5 / XULRunner 1.8 - add-ons that do not use a valid version format will not be installed. The version format is different from, although backwards-compatible with, 1.0's.

For add-ons hosted on addons.mozilla.org - Mozilla's update website may repackage your add-on and correct or reject malformed version strings.

Optional Property Reference

You may need to supply these properties, depending on the capabilities of your add-on.

aboutURL

The chrome:// URL of the extension's about dialog box. This is only useful to extensions. If this property is specified,  in the about:addons extensions list, the About... link in the extension's context menu will show this dialog, rather than the default.

Note: As of Gecko 2.0, the dialog receives the Addon object representing your add-on as a parameter.

Examples

<em:aboutURL>chrome://myext/content/about.xul</em:aboutURL>

bootstrap

A Boolean value that tells the application whether the extension is boot-strappable. At the moment this only works for add-ons with em:type="2". The default value is false. For more information, see Bootstrapped extensions.

contributor

The name(s) of additional contributors. You may specify more than one of this value to specify multiple contributors.

Examples

<em:contributor>John Doe</em:contributor>

<em:contributor>John Doe</em:contributor>
<em:contributor>Jane Doe</em:contributor>
<em:contributor>Elvis Presley</em:contributor>

creator

The name of the creator/principal developer - intended for display in the user interface.

Examples

<em:creator>John Doe</em:creator>

or

<em:creator>CoolExtension Team</em:creator>

description

A short description of the add-on - intended for display in the user interface. This description should fit on one short line of text.

Examples

<em:description>Advanced foo tools.</em:description>

developer

The name(s) of co-developers. You may specify more than one of this value to specify multiple developers.

Examples

<em:developer>Jane Doe</em:developer>
<em:developer>Koos van der Merwe</em:developer>

hasEmbeddedWebExtension

If present and given the value "true", this indicates that this add-on contains an embedded WebExtension.

<em:hasEmbeddedWebExtension>true</em:hasEmbeddedWebExtension>

homepageURL

A link to the add-on's home page - intended for display in the user interface.

Examples

<em:homepageURL>https://www.example.com/</em:homepageURL>

iconURL

A chrome:// URL to an icon to display in the add-ons list. The icon will be displayed at 32x32 in Firefox 3.6 and lower. In Firefox 4.0 and later the icon can be up to 48x48 pixels in size. If this property is not specified, a default icon is used.

<em:iconURL>chrome://myext/skin/icon.png</em:iconURL>

Note: For the above example to work you will also have to add a skin package line to your chrome.manifest file. See Chrome Registration#skin. Alternatively you can place your icon in the directory specified in your content package line.

Gecko 1.9.2 note
Starting in Gecko 1.9.2 (Firefox 3.6), you can also simply include your icon, named icon.png, in the base directory of the add-on. This allows your add-on's icon to be displayed even when the add-on is disabled, or if the manifest is missing an iconURL entry.

icon64URL

A chrome:// URL to a 64x64 pixel icon to display in the add-on's details view . If this property is not specified, the smaller icon above will be used.

<em:icon64URL>chrome://myext/skin/icon64.png</em:icon64URL>

Note: For the above example to work you will also have to add a skin package line to your chrome.manifest file. See Chrome Registration#skin. Alternatively you can place your icon in the directory specified in your content package line.

Gecko 2.0 note
Starting in Gecko 2.0 (Firefox 4.0), you can also simply include your icon, named icon64.png, in the base directory of the add-on. This allows your add-on's icon to be displayed even when the add-on is disabled, or if the manifest is missing an icon64URL entry.

localized

Allows you to localize the add-on's name, description, contributors and other metadata. The localized description must specify at least one em:locale which indicates which locales to use this information for.

Examples

This declares a set of add-on metadata to be displayed when the application is running in the de-DE locale.

<em:localized>
  <Description>
    <em:locale>de-DE</em:locale>
    <em:name>Tab Sidebar</em:name>
    <em:description>Zeigt in einer Sidebar Vorschaubilder der Inhalte aller offenen Tabs an.</em:description>
  </Description>
</em:localized>

The following properties which are described elsewhere in this page can be included in the localized property:

More documentation can be found at Localizing extension descriptions.

multiprocessCompatible

A three-state value declaring this add-on's compatibility with multiprocess Firefox, and whether Firefox should load various compatibility shims that enable some add-ons to work even if their code has not been updated for compatibility.

<em:multiprocessCompatible>true</em:multiprocessCompatible>

The possible states are as follows:

Developers are strongly encouraged to test their add-ons with the flag set to true, and if they still work properly, to release a new version of their add-on with the flag set.

We will eventually disable add-ons that don't have the flag set to true.

optionsType

The type of user-interface used for displaying the options. Accepted values are:

1 Opens optionsURL in a dialog box
2 Options are displayed inside the Add-on Manager
3 Opens optionsURL in a new tab (if the application supports that), or a dialog box

optionsType defaults to 1 if there is an optionsURL included in install.rdf or 2 if there is no optionsURL and the file options.xul exists in the root of the add-on.

<em:optionsType>2</em:optionsType>

Options can be opened in a new tab since Firefox 7.0a1. To do so, set optionsType to 3 and set optionsURL to a the path of a page to open.

<em:optionsType>3</em:optionsType>
<em:optionsURL>chrome://myaddon/content/options.html</em:optionsURL>

This section here contains an example of localized HTML page as an option panel in a new tab: Bootstrapped Extensions :: Localization (L10n) (example linked to is: GitHub :: l10n-html-options).

optionsURL

The chrome:// URL of the extension's options dialog box. This is only useful to extensions. If this property is specified, when the extension is selected in the Extensions list, the Options button is enabled and will show this.

<em:optionsURL>chrome://myext/content/options.xul</em:optionsURL>
Gecko 7 note
In Firefox 7 you can also simply include your options XUL as a file named options.xul, in the base directory of the add-on.

skinnable

A true or false value property that tells the application whether the (complete) theme can be skinned by lightweight themes/personas:

Examples

<em:skinnable>true</em:skinnable>

strictCompatibility

A Boolean value indicating if the add-on should be enabled when the version of the application is greater than its max version. By default, the value of this property is false meaning that the compatibility checking will not be performed against the max version.

<em:strictCompatibility>true</em:strictCompatibility>

Usually, there is no need to restrict the compatibility: not all new releases will break your extension and, if it is hosted on AMO, you'll get notice several weeks in advance if a potential risk has been detected. Moreover, an extension being disabled, even for a short period, leads to a bad experience for the user. About the only time you should need to set this if your add-on does things that are likely to be broken by Firefox updates. You do not need to set this flag if your add-on has a binary component, since add-ons with binary components are always subject to strict compatibility checking (because binary components need to be rebuilt for every major application release anyway).

Note: If you want to restore the old behavior of strict compatibility checking of all add-ons, regardless of the value of this setting in their manifests, you can set the extensions.strictCompatibility preference to true.

Note: Starting in Gecko 11.0, applications such as Firefox will assume add-ons that have not been updated in a very long time are no longer compatible by default.

targetPlatform

A string specifying a platform that the add-on supports. It contains either the value of OS_TARGET alone or combined with TARGET_XPCOM_ABI, separated by an underscore (_).

You can specify multiple targetPlatform properties per manifest. If any value matches the application's build parameters, it will be installed; if not, the user will get an appropriate error message.

Examples

<em:targetPlatform>WINNT_x86-msvc</em:targetPlatform>

<em:targetPlatform>Linux</em:targetPlatform>

<em:targetPlatform>Darwin_ppc-gcc3</em:targetPlatform>

<em:targetPlatform>SunOS_sparc-sunc</em:targetPlatform>

Usually, you would use only the OS part for themes or for extensions that are not fully cross-platform. For extensions including binary (compiled) components, you should never use the OS alone, but include the ABI (s) that you compiled the components with. If you want to include multiple versions of the components, you should also use Platform-specific Subdirectories.

Notes

This property was added for Firefox/Thunderbird 1.5. Previous versions of these applications will ignore the restrictions and install the add-on regardless of the platform.

translator

The name(s) of translators. You may specify more than one of this value to specify multiple translators.

Examples

<em:translator>Janez Novak</em:translator>
<em:translator>Kari Nordmann</em:translator>

unpack

A true or false value that tells the application whether the extension requires its files be unpacked into a directory in order to work or whether the extension can be loaded direct from the XPI. In versions before Gecko 2.0 all extensions were unpacked, in Gecko 2.0 and later the default is to not unpack. If an extension includes the following then it must request unpacking:

Examples

<Description about="urn:mozilla:install-manifest">
   <em:id>extension@mysite.com</em:id>
   <em:unpack>true</em:unpack>
   ...
</Description>

updateKey

 

To ensure the security of update rdf data that is retrieved over plain HTTP you must use a digital signature to verify the contents of the data. In order to do so you must include the public part of the cryptographic key in an updateKey entry in the install.rdf of the add-on. This can be generated using the McCoy tool. Any line breaks and whitespace as part of this entry are ignored.

<em:updateKey>MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDK426erD/H3XtsjvaB5+PJqbhj
              Zc9EDI5OCJS8R3FIObJ9ZHJK1TXeaE7JWqt9WUmBWTEFvwS+FI9vWu8058N9CHhD
              NyeP6i4LuUYjTURnn7Yw/IgzyIJ2oKsYa32RuxAyteqAWqPT/J63wBixIeCxmysf
              awB/zH4KaPiY3vnrzQIDAQAB</em:updateKey>

updateURL

A link to a custom Update Manifest file that specifies available updates to the add-on. The format is described below. If enabled, the add-on manager periodically checks with this Manifest file to determine if newer versions are available. When not included, the add-on manager will still check for updates on AMO, using the ID of the extension.

Note: It is strongly recommended that the updateURL be an HTTPS (secure) link. Non-secure update URLs can be hijacked by a malicious update.rdf file, enabling malware to infiltrate the user's computer. Alternatively, you could host your extension on AMO and leave out the updateURL completely. This provides secure updates automatically.

For security reasons, Gecko 1.9 applications require that if you specify an updateURL, it must be an HTTPS URL, or you must include an updateKey.

Your server must send this file as text/rdf, text/xml or application/rdf+xml or the update checker may not work.

The add-on manager will substitute the following values into this URL in case you wish to generate the response RDF dynamically, such as using PHP or CGI:

%REQ_VERSION% The version of the request. Currently 1
%ITEM_ID% The id of the add-on being updated
%ITEM_VERSION% The version of the add-on being updated
%ITEM_MAXAPPVERSION% The maxVersion of the targetApplication object corresponding to the current application for the add-on being updated.
%ITEM_STATUS% Comma separated list of the add-ons operating status in the application. Contains at the least either userEnabled or userDisabled plus any number of incompatible, blocklisted or softblocked.
%APP_ID% The id of the current application
%APP_VERSION% The version of the application to check for updates for
%CURRENT_APP_VERSION% The version of the current application
%APP_OS% The value of OS_TARGET from the Firefox build system, identifying the operating system being used.
%APP_ABI% The value of the TARGET_XPCOM_ABI value from the Firefox build system, identifying the compiler/architecture combination used to compile the current application.
%APP_LOCALE% The current application's locale.
%UPDATE_TYPE% UPDATE_TYPE_COMPATIBILITY(32), UPDATE_TYPE_NEWVERSION(64)
%COMPATIBILITY_MODE% related to default to compatible, values could be normal, ignore or strict.

Examples

<em:updateURL>https://www.example.com/update.cgi?id=%ITEM_ID%&amp;version=%ITEM_VERSION%</em:updateURL>
<em:updateURL>https://www.example.com/extension/windows.rdf</em:updateURL>

For add-ons hosted on addons.mozilla.org: You may not specify an updateURL property. By default, Mozilla applications using the Add-on Manager (such as Firefox and Thunderbird) will send update requests to addons.mozilla.org using the default web service. Every time you upload a new version of your add-on or change its compatibility parameters through the author interface, your update manifest will be generated automatically.

Format of the Update Manifest: The Update Manifest is a RDF/XML datasource. For an example of an update manifest, see Extension Versioning, Update and Compatibility.

Obsolete Property Reference

These properties were required in older versions of the Add-on Manager, but have been replaced with newer and better mechanisms.

file

Firefox 1.0 This property pointed to a chrome .jar file that contains chrome packages that require registration with the Chrome Registry.

The <em:file> property has a complex object value. The URL of the value is urn:mozilla:extension:file:jarFile.jar where jarFile.jar is the name of the jar file that contains the chrome package's files. This could also be the name of a directory that contains the chrome package's files, un-jarred (e.g. urn:mozilla:extension:file:directory). In either case, the referenced chrome package file(s) must be placed in the chrome subdirectory of the XPI's top level.

This object has a package property (with a path within the jar file or directory that leads to the location where the contents.rdf file responsible for registering that package is located), a locale property (ditto, but to register the locale) and a skin property (ditto, but to register the theme material).

In extensions for Firefox 1.5, this property is no longer necessary: the chrome.manifest at the top level of the XPI is used to locate chrome to register. If there is no chrome.manifest, this property is still read by the Add-on Manager and a chrome.manifest is generated from old-style contents.rdf.

Examples

<em:file>
  <Description about="urn:mozilla:extension:file:myext.jar">
    <em:package>content/myext/</em:package>
    <em:locale>locale/en-US/myext/</em:locale>
    <em:skin>skin/classic/myext/<em:skin>
  </Description>
</em:file>

An Install Manifest may specify multiple file properties, one for each jar file or subdirectory that contains chrome to register.

hidden

Firefox 1.0 - 3.5 A boolean value that when true makes the add-on not show up in the add-ons list, provided the add-on is installed in a restricted access area (so it does not work for add-ons installed in the profile). This is for bundling integration hooks to larger applications where having an entry in the Extensions list does not make sense.

Note: This property is no longer supported under Gecko 1.9.2 (Firefox 3.6) or later, to prevent extensions from being installed in such a way that the user might not be able to tell they're installed.

Examples

<em:hidden>true</em:hidden>

requires

Firefox 2.0 - 3.6.x. Other versions will ignore the restrictions and install the add-on regardless of the requirements.

See Replacement for install.rdf property "requires" discussion for rationale behind removing this feature and the suggested workaround.

<em:requires> has a similar syntax to the <em:targetApplication> tag (i.e. you must specify <em:id>, <em:minVersion>, <em:maxVersion> when using it). If the add-on specified by the <em:id> tag is not installed or has an incompatible version, the extension manager will disable your extension and show the message "Requires additional items". You can add as many <em:requires> tags as you like. Your extension will be disabled if any of the specified requirements fail. It is not possible to add dependencies that are specific to a <em:targetApplication>. See Extension Dependencies for more details.

Glossary

restricted access area

A restricted access area is an install location that could be restricted on a restricted-access account, regardless of whether or not the location is restricted with the current user privileges (see nsIInstallLocation::restricted). Currently, the ($APPDIR)/extensions folder and the registry install location under HKEY_LOCAL_MACHINE (see Adding Extensions using the Windows Registry for details) are restricted.

The ($PROFILE)/extensions and HKEY_CURRENT_USER install locations, on the other hand, are not restricted.