Permissions Policy Header Builder
Control powerful browser features with a clear, valid Permissions-Policy
header.
Builder
Policy configuration
Results
Introduction
The Permissions-Policy header lets you control which powerful browser features a page and its embedded content can use. You can block camera access, microphone access, geolocation, payment handlers, USB, and many other capabilities.
This builder helps you create a policy visually and reduces syntax mistakes.
How it works
Each directive consists of a browser feature and an allowlist. The tool converts your selections into standard Permissions-Policy syntax and validates common problems such as unknown features, duplicate directives, invalid origins, and risky wildcards.
- Directive rows are processed locally.
- Origins are normalized to scheme plus host.
- Unknown features generate warnings, not hard failures.
- Sensitive wildcard grants are flagged.
How to use
- Choose a preset or start with custom directives.
- Add the features you want to control.
- Select block, self, specific origins, or allow all.
- Generate the header.
- Copy the HTTP header or deployment snippet.
Practical example
A strict privacy policy may include:
Permissions-Policy: camera=(), microphone=(), geolocation=(), payment=(), usb=()This prevents the page and most embedded content from accessing those features.
Use cases
- Hardening static marketing pages.
- Restricting third-party embeds.
- Preparing security headers for Cloudflare Pages, Nginx, or Node.js.
- Reviewing feature usage before enabling new browser APIs.
- Documenting privacy controls for audits.
Best practices
- Block features you do not use.
- Use
selfwhen only your origin needs access. - List trusted origins explicitly instead of using wildcards.
- Avoid wildcards for sensitive features.
- Test in staging before production rollout.
Common mistakes
- Using invalid origin syntax.
- Forgetting quotes around origins.
- Duplicating directives accidentally.
- Blocking features required by embedded maps or payment flows.
- Assuming Permissions-Policy replaces CSP.
Limitations
- Browser feature support varies.
- Some feature names are experimental.
- The tool does not test live site behavior.
- Third-party frames may require additional allow lists or embed configuration.
Browser compatibility
Permissions-Policy support varies by browser and feature. Chromium browsers support many directives, while other browsers may support a smaller set.
FAQ
Is my policy uploaded?
No. All configuration and generation happen locally in your browser.
Does this replace Content Security Policy?
No. CSP controls script, style, and resource loading. Permissions-Policy controls powerful browser feature access.
Can I allow only trusted third parties?
Yes. Use the specific origins mode and list the exact origins that should have access.
Are unknown feature names rejected?
No. They generate warnings because some features are new, experimental, or browser-specific.