Browser Feature Tester

Every green check on this page means one thing on its own: the property or method exists on window or navigator right now. That is what feature detection can see from JavaScript, and it is not a promise that the feature will work when you call it.

Three separate gates sit between existence and a working feature. The API has to be present. The page has to be in a context where the browser is willing to expose it, usually HTTPS and often a top-level document rather than an iframe. And the user has to grant permission. Older capability testers could only inspect the first gate and told you to guess at the rest.

This one goes a step further on the third gate. For the features guarded by a permission, it reads that permission’s current state and prints it under the card, so a red result and a denied permission are no longer the same ambiguous shrug.

The Permissions API, navigator.permissions.query, reports where a permission stands without ever showing a dialog. It returns one of three states: granted, denied, or prompt. Prompt means the user has not decided yet and will be asked the first time the feature is actually used. This tool queries camera, microphone, geolocation, notifications, and clipboard read that way, all on load, because reading a state is not the same as requesting access.

That distinction is the whole point. A permission dialog only appears when a site calls the feature itself, such as getUserMedia for the camera or geolocation.getCurrentPosition for location. Querying the state is a passive read, which is why it is safe to do automatically and why this page can tell you a permission is already denied without pestering you to confirm it.

Not every browser lists every permission name, and the ones it does not recognise are shown as not queryable rather than invented as granted. So when a card shows “permission denied by the user” you can trust it, and when it shows nothing extra, the browser simply would not tell the page. WebGL, storage, and the rest have no permission line because they are not gated by a user prompt in the same way.

A green API check with a granted permission still is not a guarantee the feature will work end to end. The hardware behind it can be missing or in use by another program, a corporate policy can block it at a layer the browser does not report, and an extension can interfere after the check has run. This page raises your confidence; it does not replace trying the real thing, which is what the dedicated testers above are for.

It also cannot see a permission the browser will not expose. Where a permission name is not recognised, the state is left blank rather than guessed, so the absence of a permission line means the browser stayed silent, not that access is open. And it reads a moment in time: grant or revoke a permission in browser settings and the card only updates when you re-run the checks.

The results above are computed in this tab from your browser's own properties and permission states, and are not sent anywhere. Nothing here triggers a permission prompt, so opening this page does not expose your camera, location, or clipboard to the site.