Permissions Test

What is this tool?

The Permissions Test is a dashboard of the browser permissions a web page can hold. On load it queries the current state of ten permissions and APIs and draws each as a card reading Granted, Prompt, Denied, Not Supported or Checking, with an overview strip that counts how many sit in each state.

The ten it checks are camera, microphone, notifications, MIDI devices, hardware motion sensors (accelerometer / gyroscope / magnetometer), geolocation, iOS motion events, clipboard, persistent storage and File System Access. Each is read through navigator.permissions.query() where the browser supports it, with a feature-detect fallback for the APIs that do not answer that query.

Reading a permission's state never triggers a prompt. The native dialog only appears when you press a card's Request button, which actually invokes the underlying API — a getUserMedia stream that is stopped again immediately, a geolocation lookup, Notification.requestPermission(), and so on. Nothing you grant is stored or uploaded by the page.

How to use it

1. Open the page over HTTPSThe Permissions API and most of the permissions it reports require a secure context. On an http:// origin the cards report Not Supported because the APIs are simply absent.
2. Read the initial statesOn load the tool queries all ten permissions at once. Granted means access is already allowed, Prompt means the browser will ask when the feature is used, Denied means you previously blocked it, and Not Supported means this browser does not expose that API.
3. Request a single permissionPress Request Permission on any card in the Prompt state to raise the real browser dialog. Allowing or blocking it updates the card. Use Re-check Permissions to re-read every state after changing something.
4. Request several at onceRequest Remaining prompts only the cards still in the Prompt state; Request All walks every requestable permission; a category's Request All covers just that group. The browser still shows one dialog per permission.

What the results mean

Granted

The browser is already allowing this permission for the site, so the feature would work without a further prompt. For camera and microphone the tool opens and immediately stops a test stream to confirm it, rather than assuming.

Prompt

No decision has been made yet. The permission is available and the browser will ask the first time the feature is actually used — which is what pressing Request does here.

Denied

Access was blocked earlier. A page cannot re-ask for a denied permission; the button changes to point you at the browser's own site settings, where the block has to be cleared by hand.

Not Supported

This browser does not implement the API. File System Access and the generic motion sensors are Chromium-desktop features, so Safari and Firefox correctly read Not Supported rather than broken.

What it can detect

• Which permissions a site already holds in this browser, without changing any of them
• Which permissions are still open to a prompt versus permanently denied
• Which browser APIs (File System Access, generic sensors, MIDI) this browser exposes at all
• Whether the page is running in a secure HTTPS context, which most permissions require

Limits worth knowing

A browser can only report what the platform gives it. These are the honest boundaries of this page, so a result is never read as more than it is.

• Reading a state is not the same as holding the access. A Granted reading means the browser would allow it; the tool only actually opens camera, microphone, geolocation and the rest when you press Request.
• A denied permission cannot be re-prompted from any web page — that is a browser security rule. Clearing it means using the padlock or site-settings menu in the address bar, which no site can do for you.
• The Permissions API is uneven across browsers. Firefox throws on some query names, so the tool falls back to reporting Prompt; the state shown is the browser's best answer, not a guarantee.
• iOS gates DeviceMotion behind an explicit tap and only surfaces it on Apple hardware, so the Motion Events card behaves differently there from a desktop browser.
• Nothing is persisted. The dashboard keeps no history in local storage, so every visit re-queries from scratch.

Tips

• Run it once before reporting that a tool 'won't ask for permission' — a card in the Denied state explains exactly why the prompt never appears.
• If camera or microphone read Denied, clear the block in the address-bar site settings, then press Re-check Permissions rather than reloading.
• Not Supported on Safari or Firefox is usually correct, not a fault: File System Access and the generic sensor classes only exist in Chromium desktop browsers.

Troubleshooting

Related documentation

• AudioMicrophone TestLive level meter, waveform, spectrum and a local recording check.
• MobileGyroscope TestLive X, Y and Z rotation rate in rad/s and deg/s, a scrolling activity graph, a guided three-axis test and a five-second zero-motion check.
• MobileCompass TestLive heading in degrees with a 16-point direction label, an eight-direction target sweep, a five-second stability check and a figure-eight calibration guide.
• MobileMobile Device TestA thirteen-item capability scan of your phone — touch, sensors, screen, camera, microphone, audio, network, battery, haptics and wake lock — in one page.