Permissions-Policy Header Builder

Permissions-Policy tells the browser which powerful features your page and the frames inside it may use. Pick a feature and choose whether it is blocked outright, allowed for your own origin, allowed everywhere, or restricted to a list you write. Features are grouped by category so the one you meant to lock down is easy to find, and warnings flag the shapes that hand a capability to every embedded origin or leave a scheme off an entry in the allowlist.

The syntax is terser than it looks and easy to get subtly wrong. An empty list disables a feature everywhere, including your own page: camera=() means nobody, not "default". (self) allows the top-level document and same-origin frames, * allows any origin, and named origins go inside the parentheses in quotes with the scheme included — geolocation=(self "https://maps.example.com"). Dropping the quotes or the https:// does not raise an error; the entry is simply not understood, and the feature ends up more restricted than you intended.

The part that catches people is that this header is not the only gate. A cross-origin iframe also needs an allow attribute on the <iframe> element itself, and the two intersect: whatever the header permits, the frame still gets nothing unless the embedding tag asks for it. So camera=(self "https://widget.example") on the response and no allow="camera" on the tag produces a widget with no camera and no obvious reason why. Both sides have to agree.

Two more things worth knowing. A misspelled feature name is ignored silently rather than rejected, so a policy with a typo protects nothing and reports nothing — check the applied policy in the browser's developer tools rather than trusting the header you wrote. And this header replaced Feature-Policy, which used a different, space-separated syntax; an old example copied from a blog post will parse as nothing at all in a current browser, which again fails quietly.