Permissions Policy Builder is designed for the exact search intent behind “permissions policy generator”. Build a Permissions-Policy HTTP response header by selecting browser features and allowlists such as self, specific origins, all or none. Build a Permissions-Policy HTTP response header by selecting browser features and allowlists such as self, specific origins, all or none. Header syntax A policy directive follows Permissions-Policy: directive=allowlist . Multiple directives are comma-separated. Common allowlist forms Examples include () to block a feature, (self) to allow the document's own origin, specific quoted origins, and * where supported. Permissions Policy is not the Permissions API The policy controls whether features may be used in a document or embedded contexts; it does not itself grant user permission to camera, microphone or location. Browser support matters Directives and behavior evolve, so test the generated header against the browsers and feature set you actually support. Worked example: Permissions-Policy: geolocation=() blocks geolocation use for the document under supported implementations. Common practical uses include Harden web applications; Restrict iframe capabilities; Create deployment headers; Audit browser-feature exposure. Important limitations: Directive support varies by browser. An allowlist does not grant user-level permission. Incorrect policies can break legitimate embedded functionality. Key questions this page should answer include: What does Permissions-Policy control? Whether specified browser features are allowed to be used in a document and relevant embedded contexts. How do I block a feature? Use an empty allowlist such as directive=(). What does self mean? It allows the document's own origin for that directive. Is Permissions Policy the same as the browser Permissions API? No. Was Permissions Policy previously called Feature Policy? Yes, and the syntax has evolved, so current documentation should be used. The page should stay focused on this differentiator: Standards-first header generation with accurate allowlist syntax, iframe context and browser-support caveats. The tool should appear before the explanatory copy so a visitor can complete the task immediately, then use the supporting content to verify the method and understand the result.
How to use this tool
Header syntax
A policy directive follows Permissions-Policy: directive=allowlist. Multiple directives are comma-separated.
Common allowlist forms
Examples include () to block a feature, (self) to allow the document's own origin, specific quoted origins, and * where supported.
Permissions Policy is not the Permissions API
The policy controls whether features may be used in a document or embedded contexts; it does not itself grant user permission to camera, microphone or location.
Browser support matters
Directives and behavior evolve, so test the generated header against the browsers and feature set you actually support.
Examples
Block geolocation
<code>Permissions-Policy: geolocation=()</code> blocks geolocation use for the document under supported implementations.
Common use cases
- Harden web applications
- Restrict iframe capabilities
- Create deployment headers
- Audit browser-feature exposure
Frequently asked questions
What does Permissions-Policy control?
Whether specified browser features are allowed to be used in a document and relevant embedded contexts.
How do I block a feature?
Use an empty allowlist such as directive=().
What does self mean?
It allows the document's own origin for that directive.
Is Permissions Policy the same as the browser Permissions API?
No.
Was Permissions Policy previously called Feature Policy?
Yes, and the syntax has evolved, so current documentation should be used.