Except as otherwise noted, the content of this page is licensed under the Creative Commons Attribution 3.0 License, and code samples are licensed under the BSD License.
©2011 Google
If you don't find an answer to your question here, try the Chrome Web Store FAQ, the group, or the gallery help.
Google Chrome Extensions are applications that run inside the Chrome browser and provide additional functionality, integration with third party websites or services, and customized browsing experiences.
As long as you are using a version of Chrome that supports extensions, you already have everything you need to start writing an extension of your own. You can start by turning on Developer mode.
Click the wrench icon and select Extensions from the Tools menu. If there's a "+" next to "Developer mode", click the "+" so it turns into a "-". Now you can reload extensions, load an unpacked directory of files as if it were a packaged extension, and more. For a complete tutorial, see Getting Started.
Extensions are written using the same standard web technologies that developers use to create websites. HTML is used as a content markup language, CSS is used for styling, and JavaScript for scripting. Because Chrome supports HTML5 and CSS3, developers can use the latest open web technologies such as canvas and CSS animations in their extensions. Extensions also have access to several JavaScript APIs that help perform functions like JSON encoding and interacting with the browser.
Extensions are downloaded by the Chrome browser upon install, and are subsequently run off of the local disk in order to speed up performance. However, if a new version of the extension is pushed online, it will be automatically downloaded in the background to any users who have the extension installed. Extensions may also make requests for remote content at any time, in order to interact with a web service or pull new content from the web.
To determine which version of Chrome is currently available on each of the different platforms, visit omahaproxy.appspot.com. On that site you will see data in a format similar to:
cf,dev,#.#.###.#,#.#.###.#,mm/dd/yy,mm/dd/yy,#####,#####,##### cf,beta,#.#.###.#,#.#.###.#,mm/dd/yy,mm/dd/yy,#####,#####,##### cf,stable,#.#.###.#,#.#.###.#,mm/dd/yy,mm/dd/yy,#####,#####,##### linux,dev,#.#.###.#,#.#.###.#,mm/dd/yy,mm/dd/yy,#####,#####,##### linux,beta,#.#.###.#,#.#.###.#,mm/dd/yy,mm/dd/yy,#####,#####,##### linux,stable,#.#.###.#,#.#.###.#,mm/dd/yy,mm/dd/yy,#####,#####,##### mac,dev,#.#.###.#,#.#.###.#,mm/dd/yy,mm/dd/yy,#####,#####,##### mac,beta,#.#.###.#,#.#.###.#,mm/dd/yy,mm/dd/yy,#####,#####,##### mac,stable,#.#.###.#,#.#.###.#,mm/dd/yy,mm/dd/yy,#####,#####,##### win,canary,#.#.###.#,#.#.###.#,mm/dd/yy,mm/dd/yy,#####,#####,##### win,dev,#.#.###.#,#.#.###.#,mm/dd/yy,mm/dd/yy,#####,#####,##### win,beta,#.#.###.#,#.#.###.#,mm/dd/yy,mm/dd/yy,#####,#####,##### win,stable,#.#.###.#,#.#.###.#,mm/dd/yy,mm/dd/yy,#####,#####,##### cros,dev,#.#.###.#,#.#.###.#,mm/dd/yy,mm/dd/yy,#####,#####,##### cros,beta,#.#.###.#,#.#.###.#,mm/dd/yy,mm/dd/yy,#####,#####,#####
Each line represents information about a different platform and channel
combination. The
listed platforms are cf
(Google Chrome Frame),
linux
, mac
, win
, and
cros
(Google Chrome OS). The listed
channels are canary
, dev
, beta
,
and stable
.
The two four-part numbers after the channel represent the current and previous
versions of Chrome deployed to that platform-channel
combination. The rest of the information is metadata about when the releases
were first pushed, as well as revision numbers associated with each build.
Yes. Extensions can make cross-domain requests. See this page for more information.
Yes. Extensions are capable of making cross-domain Ajax requests, so they can call remote APIs directly. APIs that provide data in JSON format are particularly easy to use.
Yes, because V8 (Chrome's JavaScript engine) supports JSON.stringify and JSON.parse natively, you may use these functions in your extensions as described here without including any additional JSON libraries in your code.
Yes, extensions can use localStorage to store string data permanently. Using Chrome's built-in JSON functions, you can store complex data structures in localStorage. For extensions that need to execute SQL queries on their stored data, Chrome implements client side SQL databases, which may be used as well.
Yes, there are extensions that use OAuth to access remote data APIs. Most developers find it convenient to use a JavaScript OAuth library in order to simplify the process of signing OAuth requests.
Yes, using the NPAPI interface. Because of the possibility for abuse, though, we will review your extension before hosting it in the Google Chrome Extensions Gallery or Chrome Web Store.
Yes, your extension may add buttons to the Chrome browser's user interface. See browser actions and page actions for more information.
An extension may also create popup notifications, which exist outside of the browser window. See the desktop notifications documentation for more details.
No. Extensions are limited to listening to the events described in the API documentation.
Yes, extensions may pass messages to other extensions. See the message passing documentation for more information.
Yes, since extensions are built just like websites, they can use Google Analytics to track usage. However, we strongly advise you to modify the tracking code to pull an HTTPS version of the Google Analytics library. See this tutorial for more information on doing this.
No. The extensions APIs have been designed to minimize backwards
compatibility issues that can arise when new versions of the browser are
pushed. Allowing content scripts on chrome://
URLs would mean that developers would begin to rely on the DOM, CSS, and
JavaScript of these pages to stay the same. In the best case, these pages
could not be updated as quickly as they are being updated right now.
In the worst case, it could mean that an update to one
of these pages could cause an extension to break, causing key parts of the
browser to stop working for users of that extension.
The reason that replacing the content hosted at these URLs entirely is allowed is because it forces an extension developer to implement all of the functionality they want without depending on the browser's internal implementation to stay the same.
No, popups can only be opened if the user clicks on the corresponding page or browser action. An extension cannot open its popup programatically.
No, popups automatically close when the user focuses on some portion of the browser outside of the popup. There is no way to keep the popup open after the user has clicked away.
No, there are no events an extension can listen to in order to determine whether it has been installed or uninstalled. However, an extension can determine when it has been run for the first time. See this FAQ entry for information.
Extensions use HTML and CSS to define their user interfaces, so you can use standard form controls to build your UI, or style the interface with CSS, as you would a web page. Additionally, extensions can add some limited UI elements to Chrome itself.
Extensions can store up to 5MB of data in localStorage.
You can let users set options for your extension by creating an options page, which is a simple HTML page that will be loaded when a user clicks the "options" button for your extension. This page can read and write settings to localStorage, or even send options to a web server so that they can be persisted across browsers.
Chrome's built-in developer tools can be used to debug extensions as well as web pages. See this tutorial on debugging extensions for more information.
You cannot use wildcard match patterns like http://google.*/*
to match TLDs (like http://google.es
and
http://google.fr
) due to the
complexity of actually restricting such a match to only the desired domains.
For the example of http://google.*/*
, the Google domains would
be matched, but so would http://google.someotherdomain.com
.
Additionally, many sites do not own all of the TLDs for their
domain. For an example, assume you want to use
http://example.*/*
to match http://example.com
and
http://example.es
, but http://example.net
is a
hostile site. If your extension has a bug, the hostile site could potentially
attack your extension in order to get access to your extension's increased
privileges.
You should explicitly enumerate the TLDs that you wish to run your extension on.
The management API was intended to help create new tab page replacement extensions. It was not intended to fire install/uninstall events for the current extension.
An extension can check to see whether it is running for the first time by checking for the presence of a value in localStorage, and writing the value if it does not exist. For example:
var firstRun = (localStorage['firstRun'] == 'true'); if (!firstRun) { localStorage['firstRun'] = 'true'; }
Note that this check should be run in a background page, not a content script.
While developing an extension, you may find behavior that does not match the extensions documentation and may be the result of a bug in Chrome. The best thing to do is to make sure an appropriate issue report is filed, and the Chromium team has enough information to reproduce the behavior.
The steps you should follow to ensure this are:
Feature=Extensions Type=Bug chrome.tabs.executeScript
",
which will give you
this list of results.
If you identify a feature (especially if it's related to an experimental API) that could be added to improve the extension development experience, make sure an appropriate request is filed in the issue tracker.
The steps you should follow to ensure this are:
Feature=Extensions Type=Feature shortcuts
",
which will give you
this list of results.