Browser Feature Detection

What Is Browser Feature Detection?

Browser feature detection checks whether a web browser currently exposes specific JavaScript interfaces, methods, rendering contexts, or CSS capabilities. It helps developers and everyday users understand why a feature may be available in Chrome but absent or restricted in Firefox, Safari, a privacy-focused browser, or an embedded frame. The results come from checks performed in the current browser rather than an outdated compatibility table.

An EXPOSED result does not prove permission, a connected physical device, or successful operation. For example, a phone can expose DeviceOrientationEvent without producing orientation data. A camera may expose getUserMedia() while access is denied. Use a dedicated live test when you need to verify actual behavior.

How to Use Browser Feature Detection

1. Open this page in the browser you want to inspect. The passive API and CSS checks run automatically. No camera, microphone, screen-sharing, MIDI, or location permission is requested.
2. Read the four summary counts. Distinguish exposed or available capabilities from unavailable ones, explicit policy blocks, and unknown/error states. A higher count is not an overall quality score.
3. Use Search, Category, and Status filters to locate a feature, such as WebGL, Clipboard Read, IndexedDB, or CSS Grid. Clear Filters restores the full list.
4. Read each feature’s explanation. A relevant Open Related Test link takes you to a dedicated tool for more meaningful validation, if one exists.
5. Optionally select Check Permission Hints. This only queries browser-reported permission states without asking for access. Unsupported permission names display NOT QUERYABLE. Use Clear Permission Hints to discard them.
6. Choose Re-check Features after changing browser settings or opening the tool in a different context. Copy Summary or Download JSON to keep a compatibility snapshot. Test separately in HTTPS, HTTP, and iframes when those contexts matter.

How It Works

The tool checks whether interface constructors and methods are exposed, uses CSS.supports() for CSS capabilities, and attempts to obtain a small WebGL test context where relevant. Browser Permissions Policy is consulted when exposed to determine explicit policy blocks. The optional permission hints use navigator.permissions.query() after a button click. It does not activate sensitive devices, register service workers, open network connections, read clipboard contents, or write to browser storage.

Results are generated locally in the current tab. A permissions-policy decision may be unavailable even when an API is restricted; in that case the tool avoids claiming that permission was granted or denied.

Understanding Your Results

• EXPOSED / AVAILABLE: A browser API is present, a CSS capability is recognized, or a test canvas context was created. Actual access, device hardware and performance still require separate verification.
• NOT EXPOSED / UNAVAILABLE: The capability was not found or a test graphics context could not be created. An insecure page, browser preferences or OS-level limitations may be involved.
• POLICY BLOCKED: The browser's Permissions Policy API explicitly reports that the document is not allowed to use a feature. Some policy restrictions cannot be queried in every browser.
• UNKNOWN / ERROR: A check could not reach a definite conclusion, for example because an access check threw an exception. This is not equivalent to unsupported.
• GRANTED, PROMPT, DENIED or NOT QUERYABLE permission hints: Optional permission metadata, not proof that a device request will succeed or a device is present.

Browser Limitations

Some APIs require a secure context (usually HTTPS or trusted localhost), permissions, a compatible device, or the absence of restrictive iframe settings. The same browser can report different capabilities when embedded on another site. Client-side API feature detection also cannot measure actual throughput, battery health, camera quality, GPU speed or internet bandwidth. Browser vendors intentionally limit some APIs for security and privacy, and support changes over time.

Common Mistakes to Avoid

• Equating API exposure with functionality. Use dedicated camera, MIDI, GPU or sensor tests to verify real behavior.
• Treating a permission hint as an access grant. Actual permission may depend on user gesture, page policy or OS settings, even after a query returns a state.
• Assuming NOT EXPOSED means an outdated browser. An API may be experimental, unavailable in the current context, or intentionally disabled.
• Comparing raw feature counts as benchmark scores. Feature counts mix unrelated capabilities and are not standardized performance ratings.
• Ignoring HTTPS and iframe restrictions. Check the context label and test the page directly if an embedded view differs.

Frequently Asked Questions

Conclusion

Browser Feature Detection provides a filterable, local compatibility snapshot that separates API availability, known policy restrictions and unknown states. Pair it with Browser Information & User Agent or a dedicated live feature test to investigate practical browser behavior.