A WebExtension consists of a collection of files, packaged for distribution and installation. In this article, we'll quickly go through the files that might be present in a WebExtension.

Every WebExtension must contain a file called "manifest.json". This manifest can contain pointers to several other types of files:


This is the only file that must be present in every WebExtension. It contains basic metadata about the extension, such as its name, version and the permissions it requires. It also provides pointers to other files in the extension.

See the manifest.json reference page for all the details.

Background scripts

WebExtensions often need to maintain long-term state or perform long-term operations, independently of the lifetime of any particular web pages or browser windows. That's what background scripts are for.

Background scripts are loaded as soon as the extension is loaded and stay loaded until the extension is disabled or uninstalled. You can use any of the WebExtension APIs in the script, as long as you have requested the necessary permissions.

Specifying background scripts

You can include a background script using the background key in "manifest.json":

// manifest.json

"background": {
  "scripts": ["background-script.js"]

You can specify multiple background scripts: if you do, they run in the same context, just like multiple scripts that are loaded into a single web page.

Background script environment


Background scripts run in the context of special pages called background pages. This gives them a window global, along with all the standard DOM APIs that provides.

You don't have to supply your background page. If you include a background script, an empty background page will be created for you.

However, you can choose to supply your background page as a separate HTML file:

// manifest.json

"background": {
  "page": "background-page.html"

WebExtension APIs

Background scripts can use any of the WebExtension APIs in the script, as long as their extension has the necessary permissions.

Cross-origin access

Background scripts can make XHR requests to any hosts for which they have host permissions.

Browser actions

If your extension defines a browser action and that browser action does not have a popup, then you can listen to click events on the browser action's button using the browserAction's onClicked object:


Web content

Background scripts don't get direct access to web pages. However, they can load content scripts into web pages and can communicate with these content scripts using a message-passing API.

Content security policy

Background scripts are restricted from certain potentially dangerous operations, like the use of eval(), through a Content Security Policy. See Content Security Policy for more details on this.

Content scripts

Use content scripts to access and manipulate web pages. Content scripts are loaded into web pages and run in the context of that particular page.

Content scripts are extension-provided scripts which run in the context of a web page; this differs from scripts which are loaded by the page itself, including those which are provided in <script> elements within the page.

Content scripts can see and manipulate the page's DOM, just like normal scripts loaded by the page.

Unlike normal page scripts, they can:

  • make cross-domain XHR requests
  • use a small subset of the WebExtension APIs
  • exchange messages with their background scripts and in this way can indirectly access all the WebExtension APIs.

Content scripts can't directly access normal page scripts, but can exchange messages with them using the standard window.postMessage() API.

Usually, when we talk about content scripts, we're referring to JavaScript, but you can inject CSS into web pages using the same mechanism.

See the content scripts article to learn more.

Browser actions

A browser action is a button you can add to the browser toolbar. Users can click the button to interact with your extension.

You can optionally define a popup for the button using HTML, CSS, and JavaScript.

If you don't define a popup, then when the user clicks the button an event is dispatched to the extension, which you can listen for using browserAction.onClicked:


If you do define a popup, the click event is not dispatched: instead, the popup will be shown when the user clicks the button. The user will be able to interact with the popup and it will close automatically when the user clicks outside it.

Note that your extension can have only one browser action.

Specifying the browser action

You define the browser action's properties - icon, title, popup - using the browser_action key in manifest.json:

"browser_action": {
  "default_icon": {
    "19": "button/geo-19.png",
    "38": "button/geo-38.png"
  "default_title": "Whereami?",
  "default_popup": "popup/geo.html"

The only mandatory key is default_icon. You can change any of these properties programmatically using the browserAction API.


The popup is specified as an HTML file, which can include CSS and JavaScript files, just like a normal web page. Unlike a normal page, though, the JavaScript can use all the WebExtension APIs that the extension has permissions for.

Starting in Firefox 48, you can ask the browser to include a stylesheet in your popup that will make it look consistent with the browser's UI. To do this, include "browser_style": true in your browser_action key.

To close the popup programmatically, call window.close() from a script running in the popup. Note that in Firefox, this is only supported since Firefox 47.

Popups have a Content Security Policy that restricts the sources from which they can load resources, and disallows some unsafe practices such as the use of eval(). See Content Security Policy for more details on this.

Page actions

Page actions are like browser actions in most respects, except that:

  • browser actions are displayed all the time, and are for actions that are applicable more or less all the time
  • page actions are for actions which only make sense on certain pages, and are only displayed when those tabs are active.

To emphasise that page actions are closely tied to particular pages, they're shown in the address bar, rather than the main toolbar:

Page actions are specified using the page_action key in manifest.json, and can be manipulated using the pageAction API.

Unlike browser actions, they're hidden by default, and you call pageAction.show() and pageAction.hide() to show or hide them in specific tabs.

Options pages

Options pages enable you to define preferences for your WebExtension that your users can change. Users can access the options page for an add-on from the browser's add-ons manager:

The way users access the page, and the way it is integrated into the browser's user interface, will vary from one browser to another.

To create an options page:

  • write an HTML file defining the page. This file can include CSS and JavaScript files, just like a normal web page. JavaScript running in the page can can use all the WebExtension APIs that the add-on has permissions for. In particular, you can use the storage API to persist preferences.
  • package these files in your add-on
  • include an options_ui key in manifest.json, giving it the URL to the page.

You can open the page programmatically by calling runtime.openOptionsPage().

Options pages have a Content Security Policy that restricts the sources from which they can load resources, and disallows some unsafe practices such as the use of eval(). See Content Security Policy for more details on this.

Web accessible resources

Web accessible resources are resources such as images, HTML, CSS, JavaScript, that you include in the extension and want to make accessible to content scripts and page scripts. Resources which are made web-accessible can be referenced by page scripts and content scripts using a special URI scheme.

For example, if a content script wants to insert some images into web pages, you could include them in the extension and make them web accessible. Then the content script could create and append img tags which reference the images via the src attribute.



Document Tags and Contributors

 Last updated by: Sheppy,