All tools

Permissions-Policy Header Builder

Network

Build a Permissions-Policy (formerly Feature-Policy) response header from a list of browser features and their allowlists (self, none, specific origins, or all origins), with a plain-English note on what each directive restricts, or parse an existing header

Pick which browser features (camera, microphone, geolocation, fullscreen, and more) your page should be allowed to use, and what origins are allowed to use them, then get the assembled Permissions-Policy header value back with a plain-English note on what each directive actually restricts. This fills the one major security-header gap left after the site's CORS, CSP, Cache-Control, Referrer-Policy, and Vary builders: a locked-down policy is worth more once you understand it, not just once you have a string to paste. It also parses an existing header you paste in, useful for auditing a policy you found on a real response.

permissions-policyfeature-policyheadershttpsecurity

How to use Permissions-Policy Header Builder

  • 1.Toggle the features your page needs, or type a custom feature name and add it.
  • 2.For each selected feature, choose Block, Self only, All origins, or add specific https:// origins to its allowlist.
  • 3.Copy the generated Permissions-Policy header, or paste an existing one into the bottom field to get the same explanation for a header you found on a real response.

Frequently asked questions

What's the difference between an empty allowlist and "self"?
An empty allowlist, written as feature=(), disables the feature everywhere, including for your own page's top-level document. "self" allows the feature for your own origin but blocks it for any embedded cross-origin iframe.
Is this the same as the older Feature-Policy header?
It's the successor to it. Permissions-Policy uses the same directive names for most features but a different allowlist syntax (structured fields instead of a bare origin list), and Feature-Policy is deprecated in modern browsers.
Does the tool validate that a feature name is real?
It recognizes about 20 widely supported feature names and warns if you enter one it doesn't recognize, but it still includes unrecognized names as written since the spec is extensible and new features ship regularly.
Does this make a network request?
No, it only assembles or parses the header value locally. It doesn't check what your actual server sends or whether a browser currently supports a given feature.

Use via API, SDK, or MCP

cURL# Free: 1,000 req/day · Pro: 10,000 req/day
curl -X POST https://api.utilix.tech/v1/tools/permissions-policy-builder \
  -H "Authorization: Bearer utx_live_..." \
  -H "Content-Type: application/json" \
  -d '{"features":[{"feature":"camera","allowlist":[]},{"feature":"geolocation","allowlist":["self"]}],"permissionsPolicyHeader":"camera=(), geolocation=(self)"}'

Get an API key from your dashboard · Full API docs →

Related tools

Referrer-Policy Header BuilderBuild a Referrer-Policy header value from one or more policy tokens with a plain-English explanation of each and warnings for risky choices like unsafe-urlNetworkCache-Control Header BuilderBuild and explain an HTTP Cache-Control response header from directives like max-age, s-maxage, no-store, and immutableNetworkCORS Header BuilderGenerate CORS headers with nginx, Express, and Apache config snippetsNetwork