Permissions & Feature Test

Browsers keep a record, per origin, of what each site is allowed to use. The Permissions API exposes that record to JavaScript through a single call, navigator.permissions.query, which returns the stored state without asking you for anything. The table above runs that query against every name it knows about.

The names are defined by the specification and extended by each browser as it adds features. Geolocation, notifications, camera, microphone, clipboard read and write, MIDI, push, persistent storage, screen wake lock, background sync, the three motion sensors, payment handlers and storage access are the ones worth checking today. Some are implemented almost everywhere and some by one engine only, which is why the list above is entitled to be shorter than the one in the code.

A query is not a request. The distinction is in the specification and in the implementation: query reads the browser's stored decision, while the feature's own entry point — geolocation.getCurrentPosition, getUserMedia, Notification.requestPermission, navigator.clipboard.readText — is what triggers the dialogue the first time.

That is also why reading sixteen states in a few milliseconds raises nothing at all. The browser already knows the answers; it is not consulting you about anything new. Where a name is not recognised at all, the call throws a TypeError rather than returning a value, which is why unsupported names appear in their own list rather than in the table.

One consequence is worth naming: because nothing here asks for access, this page can never change what a site is allowed to do. If a permission shows as granted, it was granted at some earlier point by you or by a browser setting, not by visiting this page.

The three states are the whole vocabulary, and they behave differently in practice.

• Prompt. The default. The browser has no stored decision and will ask the first time the feature is used. On a site you have never granted anything to, this is what almost every row reads.
• Granted. A decision was made to allow access and it has not been revoked. The site can use the feature immediately, and for geolocation and camera access it often can do so repeatedly without asking again.
• Denied. Access was refused once and the browser remembers. Repeated requests fail silently rather than prompting again, which is what makes a denial a durable decision.

Two situations muddy the picture. An embedded page can have access restricted before you are asked at all, through the allow attribute on an iframe or a Permissions Policy header, in which case a feature that is available on the top-level site may simply not work inside the frame. And some permissions are tied to a session: a storage access grant for an iframe can expire, and push notifications behave differently in a private window.

The second table above is the more uncomfortable half of the story, because none of it needs a prompt and none of it can be switched off with a permission button.

• Display and layout. Screen dimensions, viewport size and device pixel ratio are readable by any script, which the screen resolution test shows on its own.
• Locale and time. Language preferences and the timezone are always available, and the timezone test shows how much they reveal.
• Hardware hints. CPU core count, memory class and the GPU renderer string come from ordinary APIs with no prompt attached.
• Fonts and graphics output. Text measurement reveals which fonts are installed, and canvas output varies with the graphics stack — the two signals behind most fingerprinting.
• Media device counts. The number of cameras and microphones is listed before any permission is granted, though the device names stay hidden until access is allowed. The camera and microphone test covers that boundary in detail.

Every browser keeps a per-site permission list you can edit, and it is worth a look if the table above shows a grant you do not remember making. In Chromium browsers it sits behind the icon at the left of the address bar, or under Settings, Privacy and security, Site settings. In Firefox it is the padlock in the address bar, or Settings, Privacy and security, Permissions. Safari puts it under Settings, Websites.

Clearing site data resets the record as well. Deleting cookies and storage for an origin returns its permissions to prompt, which is the reliable way to start again without hunting through settings.

If you are auditing rather than cleaning up, the cookies and storage test shows what the origin is allowed to keep on your device, and the private mode test covers the cases where a browser deliberately reports less. None of these pages change a permission; they only read and report.