What is the difference between Feature-Policy and Permissions-Policy?

Permissions-Policy is the renamed, current standard; Feature-Policy is the deprecated original name. They control the same browser features but Permissions-Policy uses structured-field syntax with parentheses around allowlists. New code should use Permissions-Policy.

What does a default allowlist of self mean?

self means the feature is permitted only in the top-level document and same-origin frames by default. Cross-origin iframes must be explicitly granted the feature via the allow attribute, and only if the parent policy also permits it.

How do I disable a feature entirely?

Give it an empty allowlist: Permissions-Policy: geolocation=(). That blocks the feature in the document and all frames. This is a common hardening step for features the site never uses, like camera, microphone or payment.

How does the iframe allow attribute interact with the header?

An iframe can request a feature with allow="camera; geolocation", but the embedded frame only gets it if the parent document's Permissions-Policy also allows that origin. The header defines the maximum; the allow attribute delegates within it.

Does this reference change my headers?

No. It is an offline lookup of feature names and default allowlists. You set the actual Permissions-Policy header on your server.

What is the Feature Policy / Permissions Policy Reference?

Searchable Permissions-Policy (formerly Feature-Policy) feature reference with each feature's default allowlist, structured header syntax and iframe allow-attribute inheritance. It runs free in your browser on Gera Tools, with nothing uploaded.

Feature Policy / Permissions Policy Reference

Name: Feature Policy / Permissions Policy Reference
Creator: Gera Tools
License: https://creativecommons.org/licenses/by/4.0/

Gating powerful browser features

The Permissions-Policy header (formerly Feature-Policy) lets a site declare which powerful browser features — geolocation, camera, microphone, payment, fullscreen and many more — may be used, and in which origins and frames. This reference lists the common features with their default allowlists and explains the structured syntax and iframe delegation.

How it works

Each feature is assigned an allowlist of origins permitted to use it. In Permissions-Policy structured syntax the allowlist is wrapped in parentheses:

Permissions-Policy: geolocation=(self "https://maps.example.com"), camera=(), fullscreen=*

The tokens are * (any origin), self (the document’s own origin), an explicit quoted origin list, or an empty list () to disable the feature everywhere. A cross-origin <iframe> can request a feature with allow="geolocation", but it is granted only if the parent’s policy already permits that origin — the header sets the ceiling, the allow attribute delegates beneath it.

Tips and notes

Disable unused powerful features with feature=() as a defence-in-depth step.
self is stricter than *: it excludes cross-origin frames unless explicitly delegated.
Combine the header with the iframe allow attribute to scope features to specific embeds.
Permissions-Policy uses parentheses; the legacy Feature-Policy used space-separated origins without them.
Browser support varies per feature — verify the specific feature in your target browsers.

Common features and sensible defaults

Feature	Default allowlist	Suggested policy
`camera`	`self`	`()` unless your site uses video chat
`microphone`	`self`	`()` unless your site uses audio input
`geolocation`	`self`	`(self)` or `()` depending on need
`payment`	`self`	`(self)` only; never `*`
`fullscreen`	`self`	`(self)` for media sites; `()` elsewhere
`autoplay`	`*`	`(self)` to prevent third-party autoplay
`usb`	`self`	`()` unless Web USB is required
`clipboard-read`	`self`	`()` for most sites
`clipboard-write`	`self`	`(self)` if you have copy-to-clipboard UX

Relationship to the Content-Security-Policy header

Permissions-Policy and Content-Security-Policy (CSP) are complementary but distinct. CSP controls which scripts, styles, and resources can load and execute on your page. Permissions-Policy controls which browser capabilities the page and its frames can invoke. A page can have a tight CSP that blocks inline scripts while still having an unrestricted geolocation policy, or vice versa. Both headers should be set in a complete browser security hardening strategy; this reference covers Permissions-Policy only.

Iframe delegation in depth

When you embed a third-party widget — a map, a video player, a payment form — you need to think about which features it should be allowed to access. The Permissions-Policy header on your page sets the ceiling: if your header says camera=(), no frame on the page can access the camera, regardless of what its allow attribute requests.

If your header permits camera=(self "https://video.partner.com"), then a frame from video.partner.com can additionally request camera access via allow="camera" on the <iframe> element. The frame only receives access if both conditions are met: it is a permitted origin in the header, and the allow attribute is present on the element. This two-level gate prevents frames from escalating permissions that the parent page has not explicitly approved.