What Is a Secure Context Checker?
A secure context is a document the browser considers sufficiently trustworthy for security-sensitive web features. This tool reads the browser's window.isSecureContext value, shows the page's protocol and frame status, and checks whether individual browser interfaces are exposed. It also checks the document's Permissions Policy when the browser provides a query interface. A secure context is not a certificate report, and an exposed API is not proof of permission to use it.
How to Use the Secure Context Checker
- Open this page in your normal browser; the secure-context check and API inspection run automatically without permission prompts.
- Read the Secure Context, Protocol, and Page frame summaries. A browser-reported Yes is more informative than HTTPS alone; local development addresses can also qualify.
- Review the API capability matrix. API EXPOSED means the interface exists, NOT EXPOSED means the interface was not found, and POLICY BLOCKED is shown only when the browser reports that restriction.
- Read the troubleshooting guidance. For permissions, open the linked Browser Permission Checker rather than assuming API exposure means access is granted.
- Use Re-check after updating browser settings, or Copy report to save a plain-text status summary. If clipboard access is unavailable, the report can be selected manually.
How It Works
The browser decides whether a document is a secure context. HTTPS pages generally qualify, and loopback or localhost development pages may qualify even over HTTP. An embedded HTTPS page can still be considered insecure when an ancestor frame is insecure. This tool treats window.isSecureContext as the authoritative result and uses URL and frame information only to explain it.
Each capability check is a read-only JavaScript interface test, such as checking whether navigator.mediaDevices.getUserMedia exists. Where supported, document.permissionsPolicy (or an older document.featurePolicy interface) is used to detect an explicitly reported feature restriction. No camera, microphone, geolocation, push subscription, notification prompt, or service-worker registration is triggered by scanning.
Understanding Your Results
- Secure Context: YES means the browser regards this document as a secure context, not that every API will work or that all permissions are granted.
- Secure Context: NO means the browser does not regard the document as secure. Try HTTPS for public sites and check whether an insecure embedding page affects the result.
- API EXPOSED means the browser exposes the inspected interface. Device support, user interaction, Permissions Policy, and permission prompts may still affect actual use.
- NOT EXPOSED means that API interface could not be detected; it does not prove the reason is HTTP or that your device is defective.
- POLICY BLOCKED means the browser's document-policy inspection reports a restriction. It does not mean the user specifically denied a permission.
Browser Limitations
Secure-context classifications and API support can differ by browser, version, iframe permissions, and device. Some browsers do not expose policy inspection; the tool reports that as unavailable rather than guessing. It cannot validate TLS certificate chains, test whether a hardware sensor exists, or determine whether a user has granted each API permission. Use the HTTPS Checker and Browser Permission Checker for related checks.
Common Mistakes to Avoid
- Equating HTTPS with the browser's security verdict: An HTTPS frame inside an insecure ancestor can fail the secure-context check, while localhost may pass without HTTPS.
- Assuming exposed means permitted: API presence does not grant camera, microphone, location, or clipboard privileges.
- Assuming missing means blocked by HTTP: An interface can be absent due to browser support or platform capabilities even in a secure context.
- Confusing document policy with user permissions: Permissions Policy restrictions, browser permission decisions, and API availability are different factors.
Frequently Asked Questions
Why do browsers restrict certain APIs to secure contexts?
Powerful browser features can reveal private information or change device state. Secure-context requirements reduce the risk of interception or tampering during delivery of website code.
Why does localhost count as secure even without HTTPS?
Browsers may treat loopback and localhost origins as potentially trustworthy for local development. A public website normally still needs HTTPS, and the browser's actual isSecureContext result is what matters.
Does "AVAILABLE" mean an API is already actively granted permission?
No. The updated matrix uses API EXPOSED to indicate that an interface exists, not that permission was granted or hardware is usable. Access can still require a user gesture, a permission prompt, or a compatible device.
Is any data collected by checking these APIs?
The tool inspects browser-visible feature flags entirely on the current page without accessing private camera, microphone, location, or clipboard data. The report remains in the tab unless you deliberately copy its text.
Can I fix a "No" secure context result myself?
If you run the website, serve public pages through valid HTTPS and check frame embedding. If you are a visitor, try opening the secure URL directly and contact the website owner if it remains insecure.
Conclusion
The browser's secure-context flag is a useful starting point, but API exposure, policy limits, and user permissions must be interpreted separately. For connection-specific diagnostics, try the HTTPS Checker.