Build Permissions-Policy (formerly Feature-Policy) headers to control browser feature access for your site.
The Permissions-Policy header tells the browser which powerful features a page and its embedded frames may use. This tool walks the list of policy-controlled features - geolocation, camera, microphone, payment, fullscreen, clipboard, and others - lets you set each one's allowlist (nobody, your own origin, specific origins, or everyone), and emits the complete header value to paste into your server or CDN response-header configuration. The thing people most often get wrong: the policy cannot be set from a meta tag and is ignored over plain HTTP, so a correctly generated header can still silently do nothing. Blocked features also stay detectable by JavaScript, so testing needs real API calls, not feature detection.
A concrete input and expected output from the current implementation.
Input
Block geolocation for everyone; allow camera for the site's own origin only; allow microphone for the site's own origin and for frames from https://meet.example.com
Expected output
Permissions-Policy: geolocation=(), camera=(self), microphone=(self "https://meet.example.com")
Each directive pairs a feature with its allowlist: () admits no origin, self admits only the site's own origin, and a quoted origin extends access to that embedded origin. The three comma-separated directives form the single header value to send with every response.
Each feature becomes one directive: the feature name, an equals sign, and an allowlist in parentheses - () blocks everyone, self admits only the page's own origin, quoted origins admit specific embedded origins, and * admits all origins. Directives are joined with commas into one header string. The same allowlist grammar appears in the iframe allow attribute, so the choices carry over to embedded content.
The browser applies the policy to the page and every nested frame. An embedded cross-origin frame may use a feature only if the header's allowlist (or an iframe allow attribute) grants it, and policies can only tighten as they nest - a frame can never widen what its parent allowed. Denied features remain defined in JavaScript, so failures surface as rejected promises or error callbacks at call time, not as missing APIs.
No. Permissions-Policy must arrive as a real HTTP response header, set in server, proxy, or CDN configuration, and browsers only enforce it in secure contexts (HTTPS or localhost). There is no meta-tag equivalent, so the generated value belongs in response-header settings, never in the HTML.
No. The API remains present - navigator.geolocation, getUserMedia, and requestFullscreen are all still defined - but every call fails: geolocation reports a permission error and getUserMedia rejects with NotAllowedError. Handle those failures deliberately and test real behavior in the browser rather than relying on feature detection.
The example and behavioral notes were checked against the browser implementation. Standards and primary references below define the relevant format, formula, or platform behavior.
Generate strong, random passwords with customizable length, character sets, and complexity requirements.
Analyze password strength with entropy scoring, crack-time estimates, and improvement suggestions.
Create cryptographically random strings for API keys, tokens, salts, and unique identifiers.
Create QR codes for URLs, text, Wi-Fi credentials, vCards, and more with customizable size and colors.
Scan and decode QR codes from uploaded images or your device camera to extract embedded data.
Compute MD5, SHA-1, SHA-256, and SHA-512 checksums to verify file integrity and detect tampering.