Browser permissions audit

Check what this origin is allowed to access. Separate permissions already granted, permissions that would prompt, and features your browser will not report.

Live browser snapshot Local analysis

Check what this origin is allowed to access. Separate permissions already granted, permissions that would prompt, and features your browser will not report.

This local snapshot loads automatically. Refresh after changing a browser setting.

RESULT PREVIEW

Measuring this browser…

The local snapshot will appear here automatically.

Permissions belong to a specific site

A browser permission is a decision about a particular capability at a particular origin. Allowing a map to use your location does not necessarily give a different website the same access. Conversely, a permission granted months ago may still be available to the site that requested it. Understanding that scope is more useful than treating all browser permissions as one global switch.

This audit queries the permission states that the browser makes available to this page. It also shows selected privacy and context signals. The audit does not request new camera, microphone or location access, and it cannot enumerate permissions granted to other websites. Its report is a view of the current origin, not an administrative inventory of your entire browser.

Read granted, prompt and denied in context

A state of granted means that the permission query reports access as already allowed under the current conditions. That does not necessarily mean the site is actively using the capability. For example, a camera permission can exist while no video stream is running. The audit flags granted states for review so that you can decide whether that access still makes sense.

A state of prompt generally means the browser may ask for a decision when the capability is requested. It is not the same as an active permission dialog, and this audit does not trigger one. A state of denied means access is reported as refused or unavailable under the current policy. Browser settings, an embedding document’s Permissions Policy or operating-system restrictions can influence that result.

Some permission names cannot be queried in every browser. In those cases, the report says that the state is not queryable. It does not guess from the absence of a response. A browser that lacks a permission-query interface can still have settings for the underlying feature, so use its site-settings interface for a definitive management view.

The Overview tab explains the findings. Measured data lets you search individual fields and values, while JSON report shows the complete export. Export JSON to retain a baseline, or print the findings for your own records. Review the report before sharing it: browser characteristics, token claims, and file names can reveal information about your setup.

Separate privacy preferences from enforcement

The report includes Global Privacy Control and Do Not Track when those properties are exposed. They express preferences or signals to websites; they do not prove that every recipient follows them. Global Privacy Control can have legal significance in some contexts, but this technical check is not a compliance determination. An absent property means this page did not receive the signal through that API.

The secure-context field describes whether the browser treats this page as running in a sufficiently trustworthy context for restricted APIs. HTTPS normally qualifies, and local loopback development origins are also commonly treated as trustworthy. That is why a local preview may access Web Crypto even when the address begins with HTTP. The observation does not mean that ordinary HTTP across a network provides transport encryption.

Cross-origin isolation is another context property. It depends on response policies and the surrounding browsing environment. It enables certain capabilities and memory-sharing features, but it is not an overall security score. A page can be well designed without cross-origin isolation when its functionality does not require those features.

Review access using the browser’s own controls

After running the audit, open the browser’s site information or site settings for the exact origin shown in the report. Review camera, microphone, notifications and location permissions. Remove grants that are no longer useful. Reload the page and run the audit again if you want to observe the effect of the change. Some browser interfaces group permissions differently, so the names may not match the API labels exactly.

For a broader cleanup, use the browser’s settings page that lists permissions across sites. A webpage cannot legitimately read that full list for you. The distinction matters: a tool that claims to inventory every other site’s grants without privileged access is overpromising. This audit intentionally stays within the information available to an ordinary page.

If a capability remains unavailable despite a grant, check operating-system privacy controls, enterprise policies and browser-specific restrictions. Site permission is only one layer. A microphone can be granted at the site level while the operating system blocks the browser from using it. Diagnose each layer separately instead of repeatedly toggling the same site permission.

Permission states and next actions

State or signalWhat to do with it
grantedReview whether this origin still needs the capability. It may not be actively using it.
promptNo decision is reported as pre-granted; an actual request can prompt later.
deniedCheck site settings and higher-level policy if access is expected.
Not queryableUse the browser’s settings UI; the page cannot infer the missing state.

Strengths and limitations

What this is useful for

The audit makes permission scope explicit and avoids requesting sensitive access merely to demonstrate a feature. It helps confirm how this origin’s settings are reported and provides a compact record of privacy-related context signals. The result is useful alongside the browser’s own settings interface.

What to keep in mind

The page cannot list another origin’s permissions, change browser settings or establish that a preference is respected by every service. Permission-query support differs across engines. A granted state alone does not prove that hardware works or that operating-system policy allows the browser to use it.

Common questions

Will running the audit grant any permissions?

No. Querying a permission state is different from requesting the protected capability. This tool does not call camera, microphone or geolocation acquisition methods. If your browser does not support a query, the result is labelled unavailable instead of forcing a permission prompt.

Can this list all sites that can send notifications?

No. An ordinary webpage cannot enumerate every other origin’s notification grants. Open the notification settings in your browser to review the full list. This page can only query the state associated with its own origin and the current browsing context.

Is the permission report uploaded?

Permission states and privacy signals are read in the current tab and are not sent to a remote service by the audit. Exporting a report saves the observed origin and states to a file you control. Share only the details relevant to your troubleshooting question.

Why does a local HTTP page show a secure context?

Browsers generally treat loopback addresses such as localhost as potentially trustworthy for development. That exception permits some APIs during local testing. It does not make an ordinary HTTP website on a remote host encrypted, and it should not be used to justify deploying sensitive tools without HTTPS.

Sources and further reading

50 useful tools · ↑ ↓ to navigate · Enter to open · Esc to close