What is the difference between Permissions Policy and Feature Policy?

Permissions Policy is the renamed and standardised successor to the experimental Feature-Policy header. The directive names and allowlist syntax were updated, and the legacy Feature-Policy header is deprecated, though some browsers still honour it.

How do I disable a feature for every origin including my own?

Give the feature an empty allowlist, written as feature=() in the header. For example geolocation=() blocks geolocation everywhere, including same-origin scripts and embedded frames.

How does Permissions Policy interact with iframes?

An embedded frame only gets a powerful feature if both the top document's Permissions-Policy allows the frame's origin and the iframe carries a matching allow attribute, such as allow="camera; microphone". Both gates must pass.

What does an allowlist of self mean?

self limits the feature to the document's own origin: same-origin scripts may use it, but cross-origin embedded frames may not unless explicitly delegated. It is the secure default for most sensitive features like camera and microphone.

Is Permissions Policy a replacement for asking the user for permission?

No. It is an additional gate that decides whether a feature is even available to a document or frame. The browser's runtime permission prompt still applies on top of it, so a feature must be both policy-allowed and user-granted to work.

Permissions Policy Reference

Email me this result

Get this tool's output sent to your inbox, plus one useful tool a week. No spam, unsubscribe any time.

The Permissions-Policy header lets a site declare which powerful browser features — camera, microphone, geolocation, fullscreen and more — are available to itself and to the frames it embeds. Formerly called Feature-Policy, it is a defence-in-depth control: even if a script or third-party iframe tries to use a sensitive API, the policy can deny it before the user is ever prompted. This reference lists the standard features with their default allowlist and the syntax to configure them.

How it works

A policy is a comma-separated list of feature=allowlist entries sent in the Permissions-Policy response header. Each allowlist is one of: * (all origins), () (no origin at all), self (the document’s own origin), or a parenthesised set of specific origins. When you set nothing, each feature uses its spec default — usually self, occasionally * for low-risk features like picture-in-picture.

For embedded content there are two gates: the parent’s policy must delegate the feature to the frame’s origin, and the <iframe> must request it with an allow attribute. Both must agree, and the browser’s normal permission prompt still applies on top.

Tips and examples

A typical hardening header that locks down sensors and delegates only what is needed:

Permissions-Policy: geolocation=(self), camera=(), microphone=(),
  payment=(self "https://checkout.example.com"), fullscreen=(self)

To grant a feature to an embedded frame, pair the header delegation with the iframe attribute:

<iframe src="https://maps.example.com"
        allow="geolocation 'src'"></iframe>

Remember the empty list () is the strongest setting — it disables the feature for everyone, including your own scripts. Start strict and delegate deliberately rather than leaving sensitive features on their permissive defaults.