Permissions-Policy Builder

Build a Permissions-Policy header that constrains the third-party code you did not write.

What you provide

Features to allow for your own origin

Comma-separated feature names. Everything else in the list is denied outright.

Result

11 features denied, 1 allowed for your own origin

An empty allowlist — the `()` form — denies a feature to your own page and to everything embedded in it. That second part is the reason to set this header at all: it constrains scripts and iframes you did not write and cannot audit, so an advertising frame cannot ask for the camera even if it tries. `(self)` allows your own origin only. Features not named in the header keep the browser default, which for most is "allowed for self", so listing everything you want denied is deliberate rather than redundant. Setting this header cannot break a feature you were not already using — but it will break one you were, which is why it is worth deploying with the report-only cousin first where your stack supports it.

Diagnostic telemetry

Header name: Permissions-Policy
Value: fullscreen=(self), camera=(), microphone=(), geolocation=(), payment=(), usb=(), autoplay=(), display-capture=(), accelerometer=(), gyroscope=(), magnetometer=(), interest-cohort=()
Denied: 11
Allowed for self: fullscreen
Applies to embedded framesThis is the point of the header — it constrains third-party code you did not write and cannot audit.: Yes

What this cannot tell you

Builds the header. Deploying it is up to your server or CDN configuration, and this page cannot verify it took effect.
Features not named keep the browser default, which for most is allowed for your own origin. Listing what you want denied is deliberate rather than redundant.
This cannot break a feature you were not using, but it will break one you were. Deploy with the report-only variant first where your stack supports it.
Runs entirely in your browser. Nothing is looked up, transmitted or stored.

Take this with you

How this calculation works

Permissions-Policy restricts which browser features a page and everything embedded in it may use. The second half of that is the reason to bother: an empty allowlist denies the feature to third-party frames and scripts you did not write and cannot audit, so an advertising iframe cannot ask for the camera even if it tries. The builder emits the two forms that matter — an empty list to deny outright, and self to allow your own origin only. Features you do not name keep the browser default, which for most of them is allowed for self, so naming everything you want denied is intentional.

What the results mean

feature=(): Denied outright, to your page and to everything embedded in it.
feature=(self): Allowed for your own origin only. Embedded third parties still cannot use it.
Applies to frames: The point of the header. It constrains code you did not write.
Unnamed features: Keep the browser default, which is usually allowed for self.

Common problems and fixes

A feature I use stopped working: You denied it. Move that feature to the allow list — the header cannot break something you were not using, so anything that breaks was in use.
The header has no effect: Check it is being sent — a meta tag equivalent does not exist for this header, so it must come from the server or CDN. Browser developer tools show what actually arrived.
Do I need this if I have a CSP?: They do different jobs. CSP governs what code may load and run; Permissions-Policy governs what capabilities that code may ask for. Both are worth having.

Frequently asked questions

What does Permissions-Policy actually do?

It restricts which browser features can be used on your page and in anything it embeds. Denying the camera means no script on the page, including a third-party frame, can prompt for it.

What happened to Feature-Policy?

Renamed. Permissions-Policy is the current header and its syntax differs — a list in parentheses rather than space-separated origins. Some older servers still send the old name.

Which features should I deny?

Everything you do not use. Camera, microphone, geolocation, payment, USB and screen capture are the highest-value denials for a site that needs none of them.

Put this on your own site

Free to embed, no attribution required beyond the source link the frame carries itself. It runs entirely in your visitor's browser, sets no cookies and loads no third-party script.

Embed code

<iframe src="https://runthetests.com/embed/permissions-policy-builder/" width="100%" height="560" style="border:1px solid #e5e5e5;border-radius:8px" title="Permissions-Policy Builder" loading="lazy"></iframe>

Preview it at https://runthetests.com/embed/permissions-policy-builder/. Embedded pages are marked noindex, so yours stays the canonical copy — not this one.