Permissions Policy Generator
Decide which powerful browser features your pages and the frames inside them may use. Set each feature to off, your site only, your site plus trusted origins, or everyone, and copy the Permissions-Policy header for your server together with the iframe allow attribute for embedded content.
- Runs in your browser
- No sign-up
- Free to use
How to use Permissions Policy Generator
- Start from a preset, such as “Turn off powerful features”.
- Adjust individual features; leave the rest on browser default.
- List trusted origins for embedded services that need a feature.
- Copy the header for your server and, if you embed frames, the allow attribute.
Permissions Policy Generator features
34 features
Camera, microphone, location, sensors, USB, payments, passkeys, autoplay, fullscreen and more.
Four levels
Off, own site, own site plus trusted origins, or everyone.
Correct syntax
Structured-field syntax with quoted origins, which is easy to get wrong by hand.
iframe attribute
The matching allow="…" value for embedded frames.
Ad-topic opt-out
browsing-topics=() opts out of the Topics API.
Any server
Apache, Nginx, IIS, Netlify, Vercel, Cloudflare, Express and PHP.
When to use Permissions Policy Generator
- Making sure no third-party script or ad frame can ask for the camera or location.
- Allowing an embedded map or payment form to use one feature.
- Opting a site out of interest-based ad topics.
- Satisfying a security scanner that reports a missing Permissions-Policy.
Permissions Policy Generator FAQ
What is the Permissions-Policy header?
A response header that tells the browser which features, such as camera, microphone or geolocation, the page and its frames may use. A feature that is switched off cannot even be requested, so no permission prompt appears.
What does camera=() mean?
An empty list: the feature is off for the page and every frame in it. camera=(self) allows only your own origin, and camera=* allows any origin that the frame tree grants.
Is Feature-Policy the same thing?
Feature-Policy was the earlier name and syntax. Browsers now use Permissions-Policy, so only that header is generated.
Do I also need the iframe allow attribute?
Yes, for embedded content from another origin. The header sets the upper limit; the allow attribute on the iframe grants the feature to that frame.
Does it ask the user for permission?
No. It only decides whether a feature may be requested at all. Users are still asked before a site can use the camera, microphone or location.
Can I set it with a meta tag?
No. Permissions-Policy must be sent as an HTTP header.
Why limit browser features
Modern browsers give web pages access to hardware and personal data: the camera, microphone, location, motion sensors, USB and serial devices, payment sheets and more. Each of these is protected by a permission prompt, but every script and frame on a page can trigger the prompt. A Permissions-Policy lets the site owner rule out features the site never uses, so that an advertising frame or compromised script cannot ask for them.
The header uses a list of feature names, each followed by an allowlist. An empty list, written as (), switches the feature off. (self) allows only the page’s own origin. Origins in quotes, such as (self "https://maps.example.com"), add trusted sites, and * allows any origin that the page delegates the feature to. Features not mentioned keep the browser’s default, which for most powerful features is “own site only”.
Embedded frames need two things to use a feature. The parent page’s policy must allow the frame’s origin, and the iframe element must carry an allow attribute naming the feature. The generator writes both, so an embedded video player can go fullscreen or a payment provider can show its payment sheet while everything else stays switched off.
Some entries are about privacy rather than hardware. browsing-topics=() opts the site out of the Topics API that Chrome offers for interest-based advertising, and turning off local-fonts and idle-detection removes signals that can be used for fingerprinting or tracking activity. The setting does not affect what the user can do in the browser itself.
The policy is a header only; it has no meta-tag form. Add it to the server configuration or hosting platform alongside your other security headers, then check the result with your browser’s developer tools or the HTTP Header Checker. Browsers ignore feature names they do not know, so listing a newer feature does not cause errors in older browsers.