To the extent possible under law, the editors have waived all copyright
and related or neighboring rights to this work.
In addition, as of 4 September 2026,
the editors have made this specification available under the
Open Web Foundation Agreement Version 1.0,
which is available at https://www.openwebfoundation.org/the-agreements/the-owf-1-0-agreements-granted-claims/owfa-1-0.
Parts of this work may be from another specification document. If so, those parts are instead covered by the license of that specification document.
Abstract
This specification defines the extension ID, its relationship to the extension origin, and the requirements on its uniqueness and stability.
Uniqueness of extension IDs
An extension ID is an opaque string that identifies a WebExtension. Every loaded WebExtension has an extension ID.
A user agent must not have two different currently-loaded WebExtensions with the same extension ID in the same profile. Loading a WebExtension whose extension ID matches an already-loaded WebExtension is an update of that WebExtension, not the addition of a second, distinct one.
An extension ID’s derivation from a WebExtension’s package, manifest, or other input is implementation-defined, as are its accepted character set, length, and case-sensitivity: Chrome, Firefox, and Safari each derive it from different inputs by different mechanisms, and this specification does not require them to converge on one.
Depending on the user agent, an extension ID can look like bmnlcjabdbnaibedpokdopcffdilbkco (Chrome’s derived form), {daf44bf7-a45e-4450-979c-91cf07434c3a} or my-extension@example.org (Firefox’s authored forms), or any other unique string an embedding application assigns.
An extension ID must be stable for the lifetime of a given installation of a WebExtension: reloading, restarting the user agent, or restarting the device must not change it. Whether the same extension ID is produced again for a separate installation of the same WebExtension source, on the same or a different machine, or when loading the same source both unpacked and packed, depends on how each user agent derives its IDs; this specification leaves that choice to the implementation.
Whether an extension origin’s extension-specific host is the extension ID depends on the user agent.
Chrome’s extension originhost is the extension ID directly.
Firefox’s extension originhost is a separate, randomly generated
identifier, unrelated to the extension ID, generated once per
(profile, extension) pair and persisted for the life of that
profile, deliberately so that a web page cannot learn whether a given
extension is installed by testing its ID against an observable
resource origin.
Safari’s extension originhost defaults to the extension ID, but
the embedding application can set the two independently, so they are
not guaranteed to match.
Requiring the extension ID as the extension originhost would
foreclose Firefox’s anti-fingerprinting design;
w3c/webextensions#868
documents a concrete leak of this kind through a declarativeNetRequest
redirect. Tracked at
w3c/webextensions#238 and
#896.
The extension ID is available to a privileged extension context and content script context of the WebExtension it identifies. An extension may also learn the extension ID of another, cooperating extension through APIs that name it explicitly, such as externally_connectable.
Where a user agent’s extension originhost is the extension ID, a web page that can load a resource from that origin observes the
extension ID as that resource’s host.
Conformance
Conformance requirements are expressed with a combination of descriptive assertions and RFC 2119 terminology.
The key words “MUST”, “MUST NOT”, “REQUIRED”, “SHALL”, “SHALL NOT”, “SHOULD”, “SHOULD NOT”, “RECOMMENDED”, “MAY”, and “OPTIONAL”
in the normative parts of this document
are to be interpreted as described in RFC 2119.
However, for readability,
these words do not appear in all uppercase letters in this specification.
All of the text of this specification is normative
except sections explicitly marked as non-normative, examples, and notes. [RFC2119]
Examples in this specification are introduced with the words “for example”
or are set apart from the normative text with class="example", like this:
This is an example of an informative example.
Informative notes begin with the word “Note”
and are set apart from the normative text with class="note", like this:
Chrome’s extension originhost is the extension ID directly.
Firefox’s extension originhost is a separate, randomly generated
identifier, unrelated to the extension ID, generated once per
(profile, extension) pair and persisted for the life of that
profile, deliberately so that a web page cannot learn whether a given
extension is installed by testing its ID against an observable
resource origin.
Safari’s extension originhost defaults to the extension ID, but
the embedding application can set the two independently, so they are
not guaranteed to match.
Requiring the extension ID as the extension originhost would
foreclose Firefox’s anti-fingerprinting design;
w3c/webextensions#868
documents a concrete leak of this kind through a declarativeNetRequest
redirect. Tracked at
w3c/webextensions#238 and
#896.
