Welcome What's new in Chrome extensions API reference Samples
Welcome What's new in Chrome extensions API reference Samples

Overview of Manifest V3

Key changes and features of Manifest V3.

Published on Updated on

Manifest V3 is supported generally in Chrome 88 or later. For extension features added in later Chrome versions, see the API reference documentation for support information. If your extension requires a specific API, you can specify a minimum chrome version in the manifest file.

Manifest V3 is a major step towards our vision for the extensions platform. Manifest V3 focuses on the three pillars of that vision: privacy, security, and performance, while preserving and improving our foundation of capability and webbiness.

This article summarizes the features and major changes introduced by Manifest V3. For help migrating Manifest V2 extensions to Manifest V3, or to better understand the architectural effect of these changes, see Migrate to Manifest V3.

Manifest V3 is available beginning with Chrome 88, and the Chrome Web Store has been accepting Manifest V3 extensions since January 2021.

New features and changes will be added to Manifest V3, just as they have been in earlier manifest versions.

Feature summary

There are a number of new features and functional changes for extensions using Manifest V3:

Each of these changes is summarized in the sections below.

Major features

This section introduces the most important and influential features of Manifest V3.

Service workers

Manifest V3 replaces background pages with service workers.

Like their web page counterparts, extension service workers listen for and respond to events in order to enhance the user's experience. For web service workers this typically means managing cache, preloading resources, and enabling offline web pages. While extension service workers can still do all of this, the extension package already contains a bundle of resources that can be accessed offline. As such, extension service workers tend to focus on reacting to browser events exposed by extensions APIs.

Network request modification

The way that extensions modify network requests is changing in Manifest V3. There's a new declarativeNetRequest API which lets extensions modify and block network requests in a privacy-preserving and performant way. The essence of this API is:

  • Rather than intercepting a request and modifying it procedurally, the extension asks Chrome to evaluate and modify requests on its behalf.
  • The extension declares a set of rules: patterns to match requests and actions to perform when matched. The browser then modifies network requests as defined by these rules.

Using this declarative approach dramatically reduces the need for persistent host permissions.

Some extensions may still require broad host permissions for certain use cases (such as redirecting requests). See Conditional permissions and declarativeNetRequest for details.

The blocking version of the webRequest API is restricted to force-installed extensions in Manifest V3. This is because of issues with the blocking web request approach:

Privacy
Requires excessive access to user data, because extensions need to read each network request made by the user.
Performance
Serializing and deserializing data across multiple process hops and the C++/JS boundary adds up.
Compatibility
Does not work well with event-based background execution as it requires the service worker to be running to handle every request.

This means that developers can implement many common use cases, such as content blocking, without requiring any host permissions.

Remotely hosted code

A key security improvement in Manifest V3 is that extensions can't load remote code like JavaScript or Wasm files. This lets us more reliably and efficiently review the safe behavior of extensions when they're submitted to the Chrome Web Store. Specifically, all logic must be included in the extension's package.

Instead of remote code, we recommend using remote configuration files. See the migration guide for more information.

Promises

Manifest V3 provides first-class support for promises. Most APIs support promises now, and we will eventually support promises on all appropriate methods. Promise chains, async, and await are also supported. Some API features, such as event listeners, continue to require callbacks.

For backward compatibility, many methods continue to support callbacks after promise support is added. Be aware that you cannot use both on the same function call. If you pass a callback, the function will not return a promise and if you want a promise returned do not pass a callback.

For information on using promises, see Promises on MDN. For information on converting callbacks to promises and for using them in extensions, see our own article.

Other features

There are a number of other changes introduced in Manifest V3:

Look for announcements of new Manifest V3 features as they become available.

Updated on Improve article

This site uses cookies to deliver and enhance the quality of its services and to analyze traffic. If you agree, cookies are also used to serve advertising and to personalize the content and advertisements that you see. Learn more about our use of cookies.