Build Permissions-Policy HTTP headers to control browser feature access for camera, microphone, and geolocation.
This tool assembles the Permissions-Policy response header from a few selections: pick a feature such as camera, microphone, or geolocation, pick which origins may use it, and it emits the header line to paste into your server, CDN, or reverse-proxy configuration. It maps your choices onto the header's allowlist grammar, including the empty-parens form that blocks a feature everywhere. The surprise most people hit: omitting a feature from the header does not block it. Unlisted features fall back to their default allowlist, which for most features is '*' - every origin, including third-party frames.
A concrete input and expected output from the current implementation.
Input
Block camera and microphone for every origin. Allow geolocation only for the site itself and https://maps.example.com. Leave all other features at their browser defaults.
Expected output
Permissions-Policy: camera=(), microphone=(), geolocation=(self "https://maps.example.com")
An empty parenthesized allowlist denies the feature to every origin, so camera and microphone are fully blocked. The geolocation allowlist lists self plus one quoted origin. Features not mentioned, such as fullscreen, keep their default allowlist and are unaffected.
Each feature has a fixed directive name (camera, geolocation, payment, and so on). The generator assigns the allowlist you chose: () denies every origin, self permits only the page's own origin, double-quoted origins permit named sites, and * permits all origins; combinations such as (self "https://example.com") are allowed. Directives are joined with commas into a single header value.
The header governs the document that carries it. An embedded frame ends up with the intersection of three inputs: the parent document's policy, the iframe's allow attribute, and the frame's own response header. A feature the parent denies or never delegates cannot be switched on by the frame, and when the policy blocks a feature, the API call fails (getUserMedia rejects) without showing the permission prompt.
No. Omitted directives keep the feature's default allowlist, and for most features the default is '*' - allowed for every origin, including cross-origin iframes. To block a feature you must list it explicitly with an empty allowlist (geolocation=()). Treat the header as a list of restrictions, not a list of permissions.
Not on its own. A cross-origin frame's policy is the intersection of your document's policy, the iframe's allow attribute, and the frame's own response header. Set allow on the element only if the embed genuinely needs the feature, and remember the frame can also grant itself features within what your policy and the attribute permit.
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.