Skip to main content
DeviceTry

Permission Diagnostics

Read the permission states this browser reports for your site — and see exactly which ones it could not read.

Read-only — never requests a permission

Permission Status Diagnostics

Read-only state queries — this page never triggers a prompt and never requests access

Reading permission states…

Denied something? The control lives in your browser, not in this page. Chromium browsers: click the lock/tune icon left of the address bar, find the permission, set it to Allow, then re-query. Firefox: the permissions panel is the padlock (or ⋮ → Permissions) — remove the block for this site. Safari: use the “aA” menu → Website Settings → Microphone/Camera, then reload. Because iOS Safari exposes very few permission names here, a missing row on iPhone or iPad says nothing about the actual state — decide it in the tool's own prompt. Reload this page after any change; permission states are only re-read when you ask.

How to Test

  • •Open the page and read the Reported state column — it distinguishes Granted, Denied, Prompt, Not queryable and Query error.
  • •Treat a row marked Prompt as undecided, not as granted: nothing has been allowed yet.
  • •When a permission is blocked, change it in your browser's site settings (the address-bar icon) and press Re-query states.

Browser Limitations

  • •A permission name this browser does not implement stays unknown; iOS Safari in particular exposes very few names, so a missing row there says nothing about the real state.
  • •A reported state is a browser bookkeeping value. It does not prove that a microphone or camera delivers sound or video — only a hardware test can show that.

Troubleshooting Tips

  • •Chromium browsers: click the lock/tune icon left of the address bar, set the permission to Allow, then re-query. Firefox: use the padlock (or the Permissions entry in the page menu). Safari: the aA menu → Website Settings, then reload.
  • •If the whole page reports the Permissions API as unavailable, decide the permission in the failing tool's own prompt instead — the outcome of that prompt is the real state.

About the Permission Diagnostics

The Permission Diagnostics calls navigator.permissions.query() once per permission name and reports exactly what the browser answered: granted, denied, or prompt. It never calls getUserMedia and never asks for anything, so no permission prompt appears while you read this page.

The point of the page is the difference between a blocked permission and an unknown one. A row that reads "Not queryable" or "Query error" is not a pass and not a failure — it means this browser did not answer for that name at all, and the page says so rather than quietly counting it as healthy. Coverage is not universal: Chromium browsers implement the widest set, Firefox a subset, and iOS Safari very few, which is why the card states how many names were actually read.

Tips for getting the full picture

  • Read the What that means column, not just the colour: Prompt means undecided, Denied means blocked, and Granted means permitted — none of the three tells you whether the hardware works.
  • Re-query after every change. Permission states are only re-read when the page asks, so a stale table is simply out of date.
  • Change a blocked permission in the browser, not here: Chromium uses the lock/tune icon left of the address bar, Firefox the padlock or its Permissions entry, Safari the aA menu → Website Settings.
  • If a tool still fails after the row says granted, the problem is downstream — hardware, driver, another app holding the device — not the permission.

What the states mean in practice

A permission shows Denied and the matching tool fails

Reset it at the source: open the browser's site-settings control for this page, set the permission to Allow, then reload this page and re-query. This page cannot change permissions, only read them.

The page reports that the Permissions API is unavailable

That is an unsupported or inconclusive result, not a clean bill of health: nothing was read. Open the tool that fails, trigger the feature, and answer its prompt — how the prompt resolves is the real state.

Rows change after a browser update

Browser updates can add permission names, which changes coverage rather than your settings. Re-query afterwards and read the coverage line at the top of the table rather than assuming a change.

Microphone and camera are Denied here but work on another site

Permissions are per-site, so another site being allowed says nothing about this one. Check the control in the address bar while you are on the page that actually fails.

Everything reads Granted but the microphone test still fails

Granted is permission bookkeeping, not a hardware result. A granted microphone with no signal points at the input device, its level, or another application holding the capture device — use the Microphone Test next, not this page.

FAQ

Will checking these permissions pop up prompts?

No. navigator.permissions.query() only reads the current state; that is its purpose. A prompt appears only when a page actually tries to use the feature, which this page never does.

Why does this browser show fewer rows?

Permission names are implemented unevenly. Firefox supports a subset of the names Chromium does, and iOS Safari exposes very few — a missing row there is a gap in the API surface, not a statement about your device or your settings.

What does Prompt mean — is it granted?

No. Prompt means no decision has been made yet: the feature has neither been allowed nor blocked. It will ask you the first time the feature is used, and only that answer will change the state.

Does granting here give the site access to anything?

This page grants nothing and cannot. It only reports states; access happens inside individual tools when you answer their own prompts.

Does a green Granted row mean the microphone works?

No. It means the browser is willing to hand over the device. Whether sound actually arrives is what the Microphone Test measures, and this page cannot answer it.