In Manifest V3, choose host access based on when and where your extension needs to work: declare required sites in host_permissions, request optional sites when needed, target static scripts with content_scripts.matches, or use activeTab for a user-triggered action on the current tab. These approaches are not interchangeable, and the available official examples do not verify eight published Chrome Web Store extensions.
How do you declare host permissions in Manifest V3?
Put site URL patterns in host_permissions when the extension needs ongoing access to those sites. Put API permission names—such as scripting—in the separate permissions array. For sites the extension may access only after the user opts in, declare patterns in optional_host_permissions and request access at runtime.
As an Amazon Associate I earn from qualifying purchases.
A required-access manifest can look like this:
{
"manifest_version": 3,
"name": "Example extension",
"version": "1.0",
"permissions": ["storage"],
"host_permissions": ["https://example.com/*"]
}The pattern is a host scope, not an API permission. Chrome’s permission documentation explains the manifest fields and warns that adding or changing host access can prompt users. Request the narrowest scope that supports the feature.
Which of the four patterns fits your extension?
| Pattern | When access happens | Target sites known in advance? | Typical use |
|---|---|---|---|
host_permissions |
Persistent access to declared sites | Yes | Core features that need site access without a fresh user gesture |
optional_host_permissions |
After the extension requests access and the user grants it | Usually; requestable patterns are declared | A feature users choose to enable for particular sites |
content_scripts.matches |
Automatically, on matching pages, subject to the declared setup | Yes | Static content scripts that should run on specified sites |
activeTab with scripting |
Temporarily after a user action on the current tab | No broad site list is needed for that action | One-off page actions initiated by the user |
1. Required access: host_permissions
Use this when the extension’s core behavior needs access to known sites as part of its normal operation. This is the appropriate home for required host patterns; do not put those URL patterns in permissions as if they were API names.
2. Ask only when a feature needs access: optional_host_permissions
Declare patterns the extension can request, then make the permission request when the user invokes the relevant feature. This gives the user a choice about access instead of requesting every capability at install time. Chrome recommends optional permissions where the functionality allows. The field became available to Manifest V3 extensions in Chrome 102, announced April 4, 2022; see the Chrome for Developers announcement.
3. Run a static script on selected pages: content_scripts.matches
Use content_scripts.matches to say where a statically declared content script should run. It is a script-targeting field, not a general substitute for host permissions needed by other host-sensitive APIs. Chrome’s content scripts guide distinguishes static declarations from dynamic registration and programmatic injection. Changes to content-script matches, like changes to host permissions, can trigger a warning.
Rank #2
4. Act on the current tab after a user gesture: activeTab
If a feature acts only when a user clicks the extension or otherwise invokes it, activeTab can grant temporary access to the current tab. Pair it with scripting when injecting a script programmatically. This avoids requesting persistent access to a broad list of sites for a one-off action. Google’s Focus Mode sample shows a Manifest V3 manifest declaring activeTab and scripting.
How are host permissions different from content_scripts.matches?
content_scripts.matches targets pages for automatic execution of statically declared content scripts. host_permissions declares host access for extension capabilities that need it beyond that static targeting. A matching pattern in one field should not be assumed to grant every kind of host access through the other.
For example, Google’s Web Accessible Resources Demo manifest uses content_scripts.matches for three example Glitch hosts. That illustrates static targeting; it does not establish that the sample is a published store extension or that its configuration fits another extension’s needs.
Do dynamic content scripts create another permission field?
No. Static declarations, dynamic registration, and programmatic injection are ways to manage when scripts are added or run; they are not additional host-permission manifest fields. The access decision still depends on the feature: a script that must work on known sites may need declared host access, while a user-triggered injection on the current tab may be able to use activeTab. The Chrome Extensions scripting API sample demonstrates dynamic declarations and programmatic injection.
Rank #4
Do all extensions need host permissions?
No. An extension that does not access site content or use a host-sensitive capability may not need host patterns. Google’s Chrome Prompt AI Demo manifest declares the sidePanel API without host permissions, illustrating that host access is feature-dependent.
Free tools Windows power users keep installed
One-click scans. No signup required.
Are there eight verified shipped Chrome extensions in these examples?
No. The verified examples here are official Google sample extensions and manifests; the available evidence does not establish eight extensions with current Chrome Web Store listings or publication status. Treat them as code examples, not as a verified set of shipped products. The official Chrome Extensions samples repository is useful for inspecting sample implementations, but a repository entry alone does not confirm store publication.
Quick Recap
Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.
