Permissions-Policy header builder

Client

Compose a Permissions-Policy header to allow or deny browser features such as camera, geolocation, and payment—copy the value into your server or CDN config after review.

About Permissions-Policy builder

Build a Permissions-Policy header to allow or deny camera, geolocation, payment, and other browser features locally. The interactive transform on this page runs in your browser tab—Toolcore does not need your paste for the core operation described above.

How to use this page

Paste or type in the main workspace, run the primary action from the toolbar, then copy or download the result. Use Load example when the page offers it, or URL prefill (?q= / ?qb=) so agents and tickets open the same input.

Limits and safety

Utilities here are for development and inspection—do not paste live production keys, PANs, or recovery codes into any browser tab you do not control.

Build a Permissions-Policy response header to restrict browser features—pair with the CSP builder for defense in depth.

Features

?

Use () to disable a feature, self for same-origin, or space-separated origins such as self https://embed.example.com.

Nearby workflows on Toolcore

  • CSP header builder — Build a Content-Security-Policy header from directive fields—copy for nginx, Express, or CDN configs locally. before you trust a token, digest, or key material in production.
  • Referrer-Policy builder — Pick a Referrer-Policy value and copy the HTTP header—control referrer leakage locally. before you trust a token, digest, or key material in production.
  • Cross-origin policy headers — Build COOP, COEP, and CORP response headers for isolation and embed rules—in your browser. before you trust a token, digest, or key material in production.
  • HTTP headers — Common request and response header fields—names, direction, and short summaries—filterable client-side. before you trust a token, digest, or key material in production.

Common use cases

  • Disable camera and microphone by default on a marketing site.
  • Allow payment only on checkout origins while blocking embed abuse.
  • Document feature restrictions alongside a Content-Security-Policy draft.

Common mistakes to avoid

  • Confusing Permissions-Policy with CSP

    CSP controls resource loads; Permissions-Policy controls API/feature access in the page.

  • Forgetting iframe inheritance

    Embedded third-party frames may need their own policy—test embeds after deploy.

FAQ

Is this the old Feature-Policy header?

Modern browsers use Permissions-Policy; this builder targets that syntax.

Is data sent to a server?

No. The header string is assembled locally.

How does this relate to CSP?

Use both: CSP for script/style origins, Permissions-Policy for device and API gates.

More tools

Related utilities you can open in another tab—mostly client-side.