Permissions Policy Header Generator
Build Permissions-Policy directives for selected browser features with explicit allowlists and origin scope.
Policy setup
Feature directives
Include a feature only when you want the response header to state an explicit rule for it. Custom allowlists accept self and exact HTTP(S) origins.
Camera
cameraLimits which origins may request camera access.
Microphone
microphoneLimits which origins may request microphone access.
Geolocation
geolocationLimits use of the browser geolocation feature.
Fullscreen
fullscreenLimits use of the Fullscreen API.
Payment
paymentLimits use of payment-related browser capabilities.
USB
usbLimits access to USB devices through WebUSB.
Serial
serialLimits access to serial devices through Web Serial.
Bluetooth
bluetoothLimits Bluetooth access where the directive is supported.
Display Capture
display-captureLimits screen and window capture requests.
Web Share
web-shareLimits calls to the Web Share API.
Accelerometer
accelerometerLimits accelerometer sensor access.
Gyroscope
gyroscopeLimits gyroscope sensor access.
Magnetometer
magnetometerLimits magnetometer sensor access.
Autoplay
autoplayLimits autoplay of audio and video media.
Encrypted Media
encrypted-mediaLimits access to Encrypted Media Extensions.
Picture in Picture
picture-in-pictureLimits picture-in-picture video behavior.
Passkey / WebAuthn Get
publickey-credentials-getLimits retrieval of public-key credentials through WebAuthn.
Screen Wake Lock
screen-wake-lockLimits requests that keep the screen awake.
XR Spatial Tracking
xr-spatial-trackingLimits spatial tracking used by WebXR experiences.
Clipboard Read
clipboard-readProposedLimits clipboard reads; the directive remains proposed in the W3C feature list.
Clipboard Write
clipboard-writeProposedLimits clipboard writes; the directive remains proposed in the W3C feature list.
Output
The Permissions-Policy output will appear here.
A policy can block a feature; it cannot grant permission
Permissions-Policy sits in front of browser capabilities such as camera, microphone, geolocation, fullscreen, and sensors. Allowing an origin in the header only makes that feature eligible under this policy. It does not bypass a user permission prompt, secure-context requirement, API requirement, or browser setting.
That distinction matters when debugging. A page may be allowed by Permissions-Policy and still be denied by the user, blocked because the page is not in a secure context, or fail because that browser does not implement the API.
Omitted is not the same as blocked
A directive such as camera=() explicitly disables camera for that response. Leaving camera out of the header does something different: the directive's default allowlist and normal browser rules still apply. This page therefore keeps “Include” separate from the allowlist choice instead of pretending an omitted row is denied.
self, *, and exact origins describe different boundaries
()
Explicitly allows no origin for that feature.
(self)
Allows the response's own origin, subject to the rest of the browser's checks.
*
Broadly allows the feature to origins covered by the wildcard. Use it only when that breadth is deliberate.
A custom list can combine self with exact origins such as https://video.example.com. A URL path is not an origin, so entries such as https://example.com/embed are rejected instead of being silently rewritten.
Cross-origin iframes need both sides of the policy
A response header can set the upper bound for a feature, but an embedded frame can also be constrained by its iframe allow attribute and by policy inheritance. If a cross-origin video frame needs camera access, adding its origin to the header is only one part of the setup. Check the iframe markup and the embedded document as well.
Clipboard directives still need compatibility testing
clipboard-read and clipboard-write are included as optional rows because they are implemented in some browsers, notably Chromium-based ones. The W3C feature list still marks them as proposed, so they start disabled here and are labelled rather than presented as universally standardized controls.
Keep an HTTP header on one physical line
The generated header joins directives with commas on a single line. Pretty-printing a header by inserting raw newlines can turn one field into invalid or unintended HTTP syntax in a configuration file. Server snippets preserve the same one-line field value and only wrap it in the syntax expected by that server.
The directive list changes as browser features evolve
The authoritative Permissions Policy specification is maintained by the W3C Web Application Security Working Group. The separate feature registry is useful when you need to check whether a directive is standardized, proposed, or still tied to a particular implementation. Browser support should still be tested for the exact directives your application depends on.
References: W3C Permissions Policy and W3C feature list.