Permissions Policy is the header that decides which browser features a page and its embeds may use: camera, microphone, geolocation, fullscreen, payment, and more. It is the control that stops a third-party embed from quietly accessing a device feature your page never intended to grant, and it is separate from Content Security Policy, which governs where resources load from rather than what features they may use. This builder assembles a correct Permissions-Policy header from your per-feature choices: blocked everywhere, allowed for your own origin, allowed everywhere, or allowed for a specific trusted origin.
Quick Answer: Choose an allowlist for each feature and click Build Permissions-Policy Header.
Free Online Tool
Permissions Policy Builder
Build a Permissions-Policy header, a different standard from CSP, with its own feature list.
How to Use the Permissions Policy Builder
- Choose the policy for camera: blocked, self, all, or a custom origin.
- Do the same for microphone and geolocation.
- Set fullscreen and payment to match your embeds needs.
- Enter a custom origin where you chose the custom option.
- Click Build Permissions-Policy Header.
- Paste the header into your server config and test embeds that need those features.
Key Features
- Covers camera, microphone, geolocation, fullscreen, and payment.
- Supports blocked (), self, all (*), and custom origin allowlists.
- Produces the standard feature=allowlist syntax.
- Omits features you leave unset.
- Explains each feature in plain terms.
- Runs entirely in the browser; nothing is deployed automatically.
What the Result Means
Each entry is one feature and its allowlist: () means no origin may use it, (self) means only your own origin, (*) means any origin, and a quoted origin means only that site. An embed that needs the camera but is not listed gets a denied feature, which usually shows as a silent failure in the embed, so a broken video call after deployment points straight at this header. The default for unlisted features is that they are allowed, so this header is about restricting features you do not want, not enabling ones you do.
Worked Example
A news site embeds a video player that needs fullscreen but must never access the camera or microphone. Setting camera to blocked, microphone to blocked, geolocation to a custom trusted maps origin, and fullscreen to self produces: camera=(), microphone=(), geolocation=(self “https://maps.example.com”), fullscreen=(self). The player works in fullscreen, the device features stay locked down, and any third-party script on the page cannot silently request camera access. If the site later adds a location-based store finder from a different provider, only the geolocation allowlist needs updating, while camera and microphone stay blocked, which shows how the header lets each feature be governed independently.
Best Practices and Tips
- Block camera and microphone by default unless your page genuinely uses them.
- Allow geolocation only for origins that need location, never for all.
- Test every embed after deployment, since a denied feature fails quietly.
- Pair this header with CSP: one controls features, the other controls sources.
- Review the header when adding a new embed, since each may need a feature.
Common Mistakes to Avoid
- Confusing Permissions-Policy with CSP; they control different things.
- Allowing a sensitive feature for all origins with (*).
- Forgetting that an unlisted feature stays allowed by default.
- Using the old Feature-Policy name, which browsers have replaced.
Frequently Asked Questions
What is the difference from CSP?
CSP controls where resources may load from. Permissions-Policy controls which browser features pages and embeds may use.
What does camera=() mean?
No origin, including your own page, may access the camera.
Why would an embed break after I add this?
Because the embed needs a feature this header now denies; add that origin to the feature allowlist.
Is Feature-Policy the same thing?
It was the old name. Permissions-Policy is the current standard with slightly different syntax.