Browser Permission Checker

What the Permissions API actually reports

The browser exposes a standard surface, navigator.permissions, defined by the W3C Permissions API. Query a permission name — geolocation, notifications, camera, microphone, clipboard-read, and so on — and it returns one of four states: granted (the site has it), denied (the site is blocked, usually because you said no), prompt (the site has neither, and would trigger a request if it asked), or unsupported (this browser doesn't recognise the name at all). That last state is the one people misread: 'unsupported' is not 'denied'. It means the browser's Permissions API doesn't know that name — the underlying feature might still exist, it just isn't queryable this way. Safari and Firefox support different subsets of names than Chrome, which is why the same site behaves differently across browsers.

Querying a permission is passive — reading the state never prompts and never grants anything. Only actually using a feature, or pressing a Test button here, triggers a real browser prompt. And browsers are increasingly stingy about even reporting state for fingerprinting reasons, so treat the report as 'what this browser will tell a site', which is precisely the visibility a site itself has.

Least privilege, applied to your own browser

Least privilege is the security principle that anything — a person, a program, a website — should hold only the permissions it genuinely needs, for only as long as it needs them. A maps page needs your location while you're using it; it does not need standing access to your camera, your microphone, and the right to push notifications at 2 a.m. forever. Auditing the grants a site holds turns an abstract principle into a concrete checklist: anything granted that the site doesn't visibly use is attack surface you can remove at no cost to yourself.

The high-stakes permissions deserve the most scrutiny because the downside is largest. Camera and microphone are the obvious ones — a granted mic permission means a tab can capture audio whenever it's open. Location reveals where you are. Notifications are the most abused: 'granted' is a standing channel a site (or whoever later buys or compromises it) can use to push spam and scam links straight onto your screen. Clipboard read can lift whatever you last copied, which might be a password. Grant these narrowly, and revoke them the moment a site's job is done.

Why sites over-ask — and how to push back

• Bundled requests: a site asks for notifications, location and camera on first load 'to streamline setup', long before any feature needs them. Decline on arrival; you can always grant later from site settings when a real feature actually asks.
• The notification land-grab: an enabled push channel is a marketing and re-engagement asset, which is why so many sites beg for it immediately. There's rarely a reason to grant notifications to a site you're visiting once.
• Revoking is per-site and permanent until you change it: open the browser's site settings (the lock/tune icon by the address bar) and set the permission back to Ask or Block. The state here will flip to 'prompt' or 'denied' on the next query.
• 'Prompt' is the healthy default state — it means the site has nothing yet and must ask, with you in the loop, the first time it truly needs the capability.

What a permission check can't tell you

This is presence-and-state detection, not a behaviour audit. A 'granted' camera permission means a tab is allowed to open the camera — it does not mean the camera is on right now, and the report can't show you whether or when a site exercised a permission it holds (browsers surface in-use indicators separately, like the recording dot in the tab). Use this to see what's exposed and what's been granted; use your browser's live indicators and site-settings page to see what's being used and to take it away. For payloads that arrive from outside the browser, the QR code inspector covers a different slice of the same caution.