Permissions-Policy Header Builder
The Permissions-Policy header is the modern replacement for Feature-Policy: it tells the browser which features your page and its iframes are allowed to use. Pick each feature one at a time and choose whether it's blocked entirely, allowed only for the same origin, allowed for any origin, or limited to a custom list. The tool tags the well-known features (camera, microphone, geolocation, payment, USB, etc.) by category so you don't miss the one that bites you. Warnings catch unsafe defaults — wildcards that hand the feature to every embedded origin, custom lists missing a scheme.
- accelerometerRead accelerometer
- gyroscopeRead gyroscope
- magnetometerRead magnetometer
- ambient-light-sensorRead ambient light
- cameraUse the user's camera
- microphoneUse the user's microphone
- autoplayAutoplay media
- display-captureScreen-share via getDisplayMedia
- speaker-selectionPick output audio device
- paymentUse the Payment Request API
- publickey-credentials-getUse WebAuthn
- fullscreenProgrammatically go fullscreen
- picture-in-pictureOpen PIP video
- screen-wake-lockKeep the screen awake
- xr-spatial-trackingUse WebXR spatial tracking
- geolocationRead user location
- clipboard-readRead clipboard contents
- clipboard-writeWrite to clipboard
- usbUse Web USB
- serialUse Web Serial
- bluetoothUse Web Bluetooth
- idle-detectionDetect user idle
- midiUse Web MIDI
- web-shareUse the Web Share API
Permissions-Policy: autoplay=(self), fullscreen=(self), picture-in-picture=(self), clipboard-write=(self), web-share=(self)Apply on every HTML response. Use Report-To + the `report-uri` directive (not built here) if you want browsers to send violations back to a collector.
How to use
- Start with the strict preset (everything off) and turn on only what your page actually needs.
- `self` is the right answer for most page-level features. `*` is rarely the right answer — it lets every iframe use the feature.
- Custom mode takes an allowlist of origins (`https://embed.example.com https://other.com`). `self` and `*` are tokens, anything else needs the full origin.
Frequently asked questions
- Permissions-Policy vs Feature-Policy?
- Same idea, new syntax. Feature-Policy used a space-separated list of origins per directive; Permissions-Policy uses structured-headers `feature=(origin1 origin2)`. Browsers honour Permissions-Policy now; serve both during the transition window if you support old browsers.
- Why is wildcard `*` risky?
- Wildcard hands the feature to every nested iframe — including third-party embeds you don't fully trust. If a malvertising or supply-chain compromise injects an iframe, `*` is the difference between 'they can spy with the camera' and 'they can't.'
Related tools
Referrer-Policy Header Builder
Pick a Referrer-Policy value and see exactly what `Referer` header outbound requests will send — same-origin, cross-origin HTTPS, HTTPS→HTTP downgrade.
Content-Security-Policy Builder
Build a CSP header from per-directive source lists, with three starter presets and live warnings for the dangerous wildcards.
SPF Record Builder
Compose a Sender Policy Framework TXT record from mechanisms, IPs and includes — with a live DNS-lookup counter and warnings.
Cache-Control Header Builder
Build an HTTP Cache-Control header from a visual checklist — freshness, revalidation, immutability, and the common presets.
HSTS Header Builder
Compose a Strict-Transport-Security header — max-age, includeSubDomains, preload — with a live preload-list eligibility check.
Cookie / Set-Cookie Header Builder
Compose a `Set-Cookie` response header from name/value plus the security attributes — SameSite, Secure, HttpOnly, Partitioned, Max-Age — with safety warnings.