Skip to main content
QUIETLYTIC
Cybersecurity

Permissions-Policy Builder

Turn on, off or origin-scope a browser feature per directive, then copy the header.

Local · nothing leaves this browser Set at least one directive
Esc Clear
accelerometer
autoplay
camera
clipboard-read
clipboard-write
display-capture
encrypted-media
fullscreen
geolocation
gyroscope
magnetometer
microphone
midi
payment
picture-in-picture
publickey-credentials-get
screen-wake-lock
usb
web-share
xr-spatial-tracking
Header value

Set at least one directive above.

How it works

Pick a setting for each browser feature that matters: None blocks it for every origin including your own page, Self allows only your own origin, All allows any origin including embedded iframes, and Origins scopes it to a specific list of origins typed into the text field. A directive left Unset is omitted from the header entirely.

Only directives current browsers enforce

The full W3C Permissions Policy draft names dozens more directives than are offered here — this list is limited to the set Chromium and Firefox actually enforce today, so the generated header does not carry entries no browser reads.

Example

Blocking camera and microphone everywhere except your own page, while allowing a payment origin for the payment feature, produces: camera=(self), microphone=(self), payment=("https://pay.example.com").

Frequently asked questions

What does an empty allowlist, (), actually mean?

No origin at all may use that feature, including your own page. It is the strictest setting — use (self) instead if your own page needs the feature but embedded content should not get it.

Why scope a feature to specific origins instead of just self or *?

A page embedding a third-party checkout or video widget can grant that one origin camera or fullscreen access without opening it to every other iframe on the page — the origin list is exactly for that case.

Does this header stop a feature from being used at all?

It stops it in the browser, for the origins not allowlisted — a blocked getUserMedia() call rejects instead of prompting. It has no effect on native app or server-side use of a device.

Related tools

From the intelligence desk