Manifest V3 permissions: a practical guide

Permissions are part of the product contract

A Manifest V3 permission is not just a build setting. It changes what the extension can do, what Chrome may show during installation, and what a reviewer must trust.

Start from features rather than from a copied manifest. For each feature, write the browser capability it needs, the pages it touches, and whether access must exist all the time or only after a user action. Then add the narrowest permission that satisfies that requirement.

The free Manifest V3 generator shows each permission with its purpose and likely install warning, and validates match patterns before adding them to the file.

API permissions and host permissions are different

The permissions array grants access to extension APIs such as storage, tabs, alarms, or notifications. host_permissions grants access to matching websites. A feature may need one, both, or neither.

For example, saving preferences locally needs storage but no host access. Reading data from a specific service may require a host pattern for that service. Injecting a content script requires a matching site declaration even if the script never calls a privileged extension API.

Keeping the arrays conceptually separate makes reviews easier: one answers “which browser powers?” and the other answers “on which sites?”

Prefer activeTab for user-initiated access

If a feature acts on the current page only after the user clicks the extension, activeTab may be enough. It grants temporary access to the active tab following an explicit gesture, avoiding permanent access to every matching site.

It is not a substitute for ongoing background behavior or content scripts that must run automatically. Use it when the product interaction genuinely begins with the user.

Make host patterns as narrow as the feature

Match patterns combine scheme, host, and path. https://example.com/* is materially narrower than *://*/*, and <all_urls> should be a deliberate product decision rather than a convenient default.

Before adding a pattern, ask:

• Does the extension need HTTP as well as HTTPS?
• Does it need every subdomain or only one host?
• Can the path be restricted?
• Could the user grant optional access later?

An invalid pattern can make the manifest fail to load. A valid but broad pattern can create an alarming install prompt and expand the consequences of a future bug.

Understand tabs and scripting

The tabs permission exposes sensitive properties across tabs. It is not required for every use of the Tabs API. Many basic operations work without it, especially when paired with activeTab after a user gesture.

The scripting permission allows programmatic script or style injection, but it does not independently grant access to a website. The extension also needs suitable host access or a temporary activeTab grant.

Model these as two halves of one capability: permission to perform the operation and permission to perform it on the target page.

Keep optional capabilities optional

Features that are useful to only some people can use optional_permissions or optional_host_permissions. Request them at the moment the person enables the feature and explain why the access is needed.

This reduces the initial trust request and makes the relationship between a feature and its privilege visible. Do not request optional access on startup merely to recreate a broad required permission later.

Review implied and platform-specific requirements

Some surfaces imply permissions. A side-panel implementation, for example, must declare the capability expected by the browser. Other APIs differ across Chrome and Firefox or require guarded code even when a polyfill handles their shared surface.

Before shipping, test the unpacked extension in every target browser and verify:

1. The manifest loads without warnings or rejected patterns.
2. Each feature works with exactly the declared permissions.
3. Removing a permission breaks only the capability that justified it.
4. Install and runtime prompts match the explanation shown in the product.
5. Content scripts run only on intended sites and frames.

The best manifest is not the shortest one. It is the one where every permission has a feature, every host pattern has a boundary, and every warning has an explanation a user can reasonably accept.