Every extension, installable web app, and theme has a
JSON-formatted manifest file,
named manifest.json,
that provides important information.
The following code shows the supported manifest fields, with links to the page that discusses each field. The only fields that are always required are name and version.
{
// Required
"name": "My Extension",
"version": "versionString",
"manifest_version": 2,
{{?is_apps}}
"app": {...},
{{/is_apps}}
// Recommended
"description": "A plain text description",
"icons": { ... },
"default_locale": "en",
{{^is_apps}}
// Pick one (or none)
"browser_action": {...},
"page_action": {...},
"theme": {...},
"app": {...},
{{/is_apps}}
// Add any of these that you need
"background": {"persistent": false, ...},
"background": {"persistent": true, ...},
{{^is_apps}}
"chrome_url_overrides": {...},
{{/is_apps}}
"content_scripts": [...],
"content_security_policy": "policyString",
"file_browser_handlers": [...],
"file_handlers": {...},
"homepage_url": "http://path/to/homepage",
"incognito": "spanning" or "split",
"key": "publicKey",
"minimum_chrome_version": "versionString",
"nacl_modules": [...],
"kiosk_enabled": true,
"offline_enabled": true,
"omnibox": { "keyword": "aString" },
{{^is_apps}}
"options_page": "aFile.html",
{{/is_apps}}
"permissions": [...],
"plugins": [...],
"requirements": {...},
"update_url": "http://path/to/updateInfo.xml",
"web_accessible_resources": [...],
"sandbox": [...]
}
This section covers fields that aren't described in another page. For a complete list of fields, with links to where they're described in detail, see the Field summary.
Used by packaged apps to specify the app's background scripts. Also used by hosted apps to specify the URLs that the app uses.
Specifies the subdirectory of _locales
that contains the default strings for this extension.
This field is required in extensions
that have a _locales directory;
it must be absent in extensions
that have no _locales directory.
For details, see
Internationalization.
A plain text string (no HTML or other formatting; no more than 132 characters) that describes the extension. The description should be suitable for both the browser's extension management UI and the Chrome Web Store. You can specify locale-specific strings for this field; see Internationalization for details.
Used by packaged apps
to specify what types of files the app can handle. An app can have multiple file_handlers, with each one having an identifier, a list of MIME types and/or a list of file extensions that can be handled, and
a title. The app can handle a file if it either has a matching file extension or
has a matching MIME type.
You can use a wildcard "*" in types or
extensions to indicate that the app can handle any file type or
"type/*" in types to indicate that the app
can handle any file with a MIME type of type.
Here's an example of specifying file handlers:
"file_handlers": {
"text": {
"types": [
"text/*"
],
"title": "Text editor"
},
"image": {
"types": [
"image/png",
"image/jpeg"
],
"extensions": [
"tiff"
]
"title": "Image editor"
},
"any": {
"extensions": [
"*"
]
"title": "Any file type editor"
}
}
To handle files, apps also need to declare the $ref:fileSystem permission. Apps can then be passed files in the $ref:app.runtime.onLaunched event - either from the system file manager (currently supported on ChromeOS only) or by providing a path on the command line.
The URL of the homepage for this extension. The extensions management page (chrome://extensions) will contain a link to this URL. This field is particularly useful if you host the extension on your own site. If you distribute your extension using the Chrome Web Store, the homepage URL defaults to the extension's own page.
One or more icons that represent the extension, app, or theme. You should always provide a 128x128 icon; it's used during installation and by the Chrome Web Store. Extensions should also provide a 48x48 icon, which is used in the extensions management page (chrome://extensions). You can also specify a 16x16 icon to be used as the favicon for an extension's pages. The 16x16 icon is also displayed in the experimental extension infobar feature.
Icons should generally be in PNG format, because PNG has the best support for transparency. They can, however, be in any format supported by WebKit, including BMP, GIF, ICO, and JPEG. Here's an example of specifying the icons:
"icons": { "16": "icon16.png",
"48": "icon48.png",
"128": "icon128.png" },
You may provide icons of any other size you wish, and Chrome will attempt to use the best size where appropriate. For example, Windows often requires 32-pixel icons, and if the app includes a 32-pixel icon, Chrome will choose that instead of shrinking a 48-pixel icon down. However, you should ensure that all of your icons are square, or unexpected behavior may result.
If you upload your extension, app, or theme using the Chrome Developer Dashboard, you'll need to upload additional images, including at least one screenshot of your extension. For more information, see the Chrome Web Store developer documentation.
Either "spanning" or "split", to specify how this extension will behave if allowed to run in incognito mode.
The default for extensions is "spanning", which means that the extension will run in a single shared process. Any events or messages from an incognito tab will be sent to the shared process, with an incognito flag indicating where it came from. Because incognito tabs cannot use this shared process, an extension using the "spanning" incognito mode will not be able to load pages from its extension package into the main frame of an incognito tab.
The default for installable web apps is "split", which means that all app pages in an incognito window will run in their own incognito process. If the app or extension contains a background page, that will also run in the incognito process. This incognito process runs along side the regular process, but has a separate memory-only cookie store. Each process sees events and messages only from its own context (for example, the incognito process will see only incognito tab updates). The processes are unable to communicate with each other.
As a rule of thumb, if your extension or app needs to load a tab in an incognito browser, use split incognito behavior. If your extension or app needs to be logged into a remote server or persist settings locally, use spanning incognito behavior.
This value can be used to control the unique ID of an extension, app, or theme when it is loaded during development.
Note: You don't usually need to use this value. Instead, write your code so that the key value doesn't matter by using relative paths and $ref:runtime.getURL.
To get a suitable key value, first
install your extension from a .crx file
(you may need to
upload your extension
or package it manually).
Then, in your
user
data directory, look in the file
Default/Extensions/<extensionId>/<versionString>/manifest.json.
You will see the key value filled in there.
The version of Chrome that your extension, app, or theme requires, if any. The format for this string is the same as for the version field.
A short, plain text string (no more than 45 characters) that identifies the extension. The name is used in the install dialog, extension management UI, and the store. You can specify locale-specific strings for this field; see Internationalization for details.
One or more mappings from MIME types to the Native Client module that handles each type. For example, the bold code in the following snippet registers a Native Client module as the content handler for the OpenOffice spreadsheet MIME type.
{
"name": "Native Client OpenOffice Spreadsheet Viewer",
"version": "0.1",
"description": "Open OpenOffice spreadsheets, right in your browser.",
"nacl_modules": [{
"path": "OpenOfficeViewer.nmf",
"mime_type": "application/vnd.oasis.opendocument.spreadsheet"
}]
}
The value of "path" is the location of a Native Client manifest
(a .nmf file)
within the extension directory.
For more information on Native Client and .nmf files, see the
Native Client Technical Overview.
Each MIME type can be associated with only one .nmf file,
but a single .nmf file might handle multiple MIME types.
The following example shows an extension
with two .nmf files
that handle three MIME types.
{
"name": "Spreadsheet Viewer",
"version": "0.1",
"description": "Open OpenOffice and Excel spreadsheets, right in your browser.",
"nacl_modules": [{
"path": "OpenOfficeViewer.nmf",
"mime_type": "application/vnd.oasis.opendocument.spreadsheet"
},
{
"path": "OpenOfficeViewer.nmf",
"mime_type": "application/vnd.oasis.opendocument.spreadsheet-template"
},
{
"path": "ExcelViewer.nmf",
"mime_type": "application/excel"
}]
}
Note: You can use Native Client modules in extensions without specifying "nacl_modules". Use "nacl_modules" only if you want the browser to use your Native Client module to display a particular type of content.
Whether the packaged app is designed to expected to work in ChromeOS kiosk mode. In kiosk mode, the platform app window will cover the entire surface of the display (forced full screen). The kiosk-enabled apps are expected to be designed with this constraint in mind.
Whether the app or extension is expected to work offline. When Chrome detects that it is offline, apps with this field set to true will be highlighted on the New Tab page.
Technologies required by the app or extension. Hosting sites such as the Chrome Web Store may use this list to dissuade users from installing apps or extensions that will not work on their computer. Supported requirements currently include "3D" and "plugins"; additional requirements checks may be added in the future.
The "3D" requirement denotes GPU hardware acceleration. The "webgl" requirement refers to the WebGL API. For more information on Chrome 3D graphics support, see the help article on WebGL and 3D graphics. You can list the 3D-related features your app requires, as demonstrated in the following example:
"requirements": {
"3D": {
"features": ["webgl"]
}
}
The "plugins" requirement indicates if an app or extension requires NPAPI to run. This requirement is enabled by default when the manifest includes the "plugins" field. For apps and extensions that still work when plugins aren't available, you can disable this requirement by setting NPAPI to false. You can also enable this requirement manually, by setting NPAPI to true, as shown in this example:
"requirements": {
"plugins": {
"npapi": true
}
}
One to four dot-separated integers identifying the version of this extension. A couple of rules apply to the integers: they must be between 0 and 65535, inclusive, and non-zero integers can't start with 0. For example, 99999 and 032 are both invalid.
Here are some examples of valid versions:
"version": "1" "version": "1.0" "version": "2.10.2" "version": "3.1.2.4567" The autoupdate system compares versions to determine whether an installed extension needs to be updated. If the published extension has a newer version string than the installed extension, then the extension is automatically updated.
The comparison starts with the leftmost integers. If those integers are equal, the integers to the right are compared, and so on. For example, 1.2.0 is a newer version than 1.1.9.9999.
A missing integer is equal to zero. For example, 1.1.9.9999 is newer than 1.1.
For more information, see Autoupdating.
One integer specifying the version of the manifest file format your package
requires. As of Chrome 18, developers should specify 2
(without quotes) to use the format as described by this document:
"manifest_version": 2
Consider manifest version 1 deprecated as of Chrome 18. Version 2 is
not yet required, but we will, at some point in the not-too-distant
future, stop supporting packages using deprecated manifest versions. Extensions,
applications, and themes that aren't ready to make the jump to the new manifest
version in Chrome 18 can either explicitly specify version 1, or
leave the key off entirely.
The changes between version 1 and version 2 of the manifest file format are
described in detail in the
manifest_version documentation.
Setting manifest_version 2 in Chrome 17 or lower is not
recommended. If your extension needs to work in older versions of Chrome,
stick with version 1 for the moment. We'll give you ample warning before
version 1 stops working.
An array of strings specifying the paths (relative to the package root) of
packaged resources that are expected to be usable in the context of a web page.
For example, an extension that injects a content script with the intention of
building up some custom interface for example.com would whitelist
any resources that interface requires (images, icons, stylesheets, scripts,
etc.) as follows:
{
...
"web_accessible_resources": [
"images/my-awesome-image1.png",
"images/my-amazing-icon1.png",
"style/double-rainbow.css",
"script/double-rainbow.js"
],
...
}
These resources would then be available in a webpage via the URL
chrome-extension://[PACKAGE ID]/[PATH], which can be generated with
the $ref:runtime.getURL method. Whitelisted resources are served with appropriate
CORS headers, so they're available via
mechanisms like XHR.
Injected content scripts themselves do not need to be whitelisted.
Prior to manifest version 2 all resources within an extension could be accessed from any page on the web. This allowed a malicious website to fingerprint the extensions that a user has installed or exploit vulnerabilities (for example XSS bugs)within installed extensions. Limiting availability to only resources which are explicitly intended to be web accessible serves to both minimize the available attack surface and protect the privacy of users.
Resources inside of packages using manifest_version
2 or above are blocked by default, and must be whitelisted
for use via this property.
Resources inside of packages using manifest_version 1 are available
by default, but if you do set this property, then it will be treated as
a complete list of all whitelisted resources. Resources not listed will be
blocked.
Defines an collection of app or extension pages that are to be served in a sandboxed unique origin, and optionally a Content Security Policy to use with them. Being in a sandbox has two implications:
postMessage()).A sandboxed page is not subject to the
Content Security Policy
(CSP) used by the rest of the app or extension (it has its own separate
CSP value). This means that, for example, it can use inline script and
eval.
For example, here's how to specify that two extension pages are to be served in a sandbox with a custom CSP:
{
...
"sandbox": {
"pages": [
"page1.html",
"directory/page2.html"
]
// content_security_policy is optional.
"content_security_policy":
"sandbox allow-scripts; script-src https://www.google.com"
],
...
}
If not specified, the default content_security_policy value is
sandbox allow-scripts allow-forms. You can specify your CSP
value to restrict the sandbox even further, but it must have the sandbox
directive and may not have the allow-same-origin token (see
the
HTML5 specification for possible sandbox tokens).
Note that you only need to list pages that you expected to be loaded in
windows or frames. Resources used by sandboxed pages (e.g. stylesheets or
JavaScript source files) do not need to appear in the
sandboxed_page list, they will use the sandbox of the page
that embeds them.
"Using eval in Chrome Extensions. Safely." goes into more detail about implementing a sandboxing workflow that enables use of libraries that would otherwise have issues executing under extension's default Content Security Policy.
Sandboxed page may only be specified when using
manifest_version 2 or above.