Permissions-Policy बिल्डर

(Documentation in English)

What it does

The Permissions-Policy HTTP header tells the browser which powerful web features your page — and every iframe you embed — is allowed to use. Camera, microphone, geolocation, sensors, USB, screen sharing: by default each of these is available to your own origin, waiting for a script to ask for it.

This tool turns that header from a hand-typed string into a structured directive editor. Each directive card names a feature — known features carry a privacy-impact badge (high / medium / low) and a note on what the feature does — and picks an allowlist: allow everywhere (*), same-origin only (self), disabled outright (()), or a custom origin list. The header assembles itself, live, beside the controls. Paste an existing header to load and edit it.

How to use it

1. Start from a preset — All deny (every catalog feature disabled), Camera self (camera=(self)), or Fullscreen * (fullscreen=*).
2. Edit the directive cards — type a feature name, pick its allowlist (Off / Self / All / Origins), and for Origins give a space-separated origin list. Add or remove directives freely.
3. Paste an existing header — expand the import panel, paste your current Permissions-Policy value, and Parse & load brings it into the editor (the header name prefix and quoted origins are handled; malformed input is reported).
4. Copy or download — copy the header for your server / CDN config, or download it as permissions-policy.txt.
5. Share the setup — your whole directive list is encoded in the page URL; copy the address to hand someone the exact policy.

Examples

A strict default for a site that needs none of these APIs:

camera=(), display-capture=(), geolocation=(), hid=(), idle-detection=(),
microphone=(), serial=(), usb=(), xr-spatial-tracking=()

Embedding a video partner that needs camera + microphone only on its own frame:

camera=(https://partner.example.com), geolocation=(), microphone=(https://partner.example.com)

Keeping fullscreen and payment for yourself, everything else locked:

fullscreen=(self), payment=(self)

Good to know

• Live validation — the tool flags duplicate directives (only the last one survives the header), * on the sensitive trio (camera, geolocation, microphone — every origin gets the hardware prompt), and names outside the catalog (typo, or a feature browsers don’t know yet — ignored silently).
• Why lock features you never use? A disabled feature cannot be re-enabled by a compromised dependency, a rogue ad script, or an injected iframe. It also shrinks your fingerprinting surface — sensor and battery APIs are classic tracking vectors.
• Feature detection still works. Scripts calling navigator.mediaDevices on a disabled feature get a rejected promise rather than a prompt — set allow="camera" only on the specific iframes that need it.
• This is not CSP. Content-Security-Policy controls what content loads; Permissions-Policy controls what hardware/APIs may be used. Ship both.
• 100% client-side — the header is built in your browser; nothing is uploaded.
• Related tools: CSP Builder, Basic Auth Generator.