What is feature detection, and why is it better than checking the browser's name?
Feature detection asks the browser directly whether it provides an API or a CSS feature — whether navigator.serviceWorker exists, what CSS.supports() answers for a declaration, what HTMLMediaElement.canPlayType() says for a codec — instead of guessing from the user-agent string. It reflects the real browser, its version and its settings, including features switched off by policy or privacy modes. A positive answer means the feature is exposed, not that every part of it works, so the critical paths still need testing on real devices.
How to use Browser Feature Checker
- Open this page in the browser you want to test — the one where a bug was reported, or the device in your test lab.
- Press Check this browser. The checks take a moment and show no prompts.
- Read the summary, then the groups: Supported, Probably and Granted mean the feature is there; Not supported, Denied and Could not be tested mean it is not, or could not be confirmed.
- Press Copy report or Download CSV and attach the result to the bug report or test record.
Browser Feature Checker features
- 34 web APIs checked by detecting the objects themselves — service workers, WebAssembly, WebGL and WebGPU, WebAuthn, Web Share, Bluetooth, USB, Serial, View Transitions, Popover and more
- 16 CSS features tested with CSS.supports(): grid and subgrid, container queries, :has(), nesting, color-mix(), OKLCH, anchor positioning, cascade layers and others
- 12 media formats: H.264, HEVC, VP9 and AV1 video, AAC, Opus, MP3 and FLAC audio from canPlayType(), WebP and AVIF from decoding a tiny embedded image, plus Media Source Extensions and Picture-in-Picture
- Storage: cookies, localStorage and sessionStorage write tests, IndexedDB, Cache API, the origin private file system, this site's storage quota and whether storage is persistent
- Five permission states read with the Permissions API, which never shows a prompt
- A summary per group, the exact test behind every row, and the page context (secure context, cross-origin isolation, reduced motion, colour scheme)
- Copy the result as a text report or download it as CSV for a bug ticket; nothing is sent anywhere
Inputs and outputs
Inputs
- The browser itself — nothing to type; the checks run when you press Check this browser.
- The page context: secure context (HTTPS), cross-origin isolation and the site's Permissions-Policy, which some features depend on.
Outputs
- Summary — supported, playable, available or granted rows per group, against the number of rows.
- Five tables — Web APIs, CSS, Media formats, Storage and Permission states — with the feature, the result and how it was tested.
- About this browser — user agent, secure context, cross-origin isolation, touch points, pixel ratio, reduced-motion and colour-scheme preferences.
- Copy report and Download CSV — the same results as text or as a CSV file.
Browser Feature Checker example
A current desktop browser
Input:
Check this browserOutput:
Web APIs 30/34 supported · CSS 16/16 supported · Media formats 10/12 playable or decodable · Storage 7/8 available · Permission states 1/5 granted
WebGPU — Supported — 'gpu' in navigator
HEVC / H.265 video — Not supported — video/mp4; codecs="hvc1.1.6.L93.B0"
AVIF images — Supported — decode a 2×2 AVIF
Notifications — Will ask — permissions.query({ name: 'notifications' })How to read the Browser Feature Checker results
"Supported" means the browser exposes the API or accepts the CSS; it does not prove that every part works. Treat it as "worth testing here", and test the real feature where it matters.
"Probably" and "Maybe" are the browser's own confidence for a media format. "Probably" is a strong yes; "Maybe" often means the container is known but the codec depends on the device.
"Granted", "Denied" and "Will ask" are the current permission states for this site; "Will ask" means a prompt would appear the first time a page requests it.
SharedArrayBuffer usually shows "Not supported" on ordinary pages: browsers expose it only to cross-origin isolated pages, which the About this browser section reports.
"Blocked by a setting" on storage means the browser refuses to store data for this site, for example because a privacy setting blocks site data.
When to use Browser Feature Checker
- Attaching the exact capabilities of a tester's or customer's browser to a bug report.
- Checking a device in a test lab before running a compatibility test plan.
- Confirming that a feature your release depends on — WebGPU, container queries, AVIF — is available in the browsers on your support list.
- Seeing whether a company policy, a privacy setting or an extension switched a feature off.
Troubleshooting
- Many results say "Could not be tested" — a script blocker or a strict privacy extension interfered; allow scripts on this page or test in a clean profile.
- WebGL shows "Not supported" on a capable computer — hardware acceleration is off in the browser settings, or the graphics driver is blocklisted by the browser.
- Storage shows "Blocked by a setting" — site data is blocked for this site; check the browser's cookie and site-data settings.
- A permission shows "Cannot be queried" — this browser does not support that permission name in the Permissions API; it says nothing about the setting itself.
Frequently asked questions about Browser Feature Checker
How is this different from looking a feature up on caniuse.com?
caniuse.com says which browser versions support a feature in general. This page asks the browser in front of you, so the answer also reflects your exact version, its settings, company policies, privacy modes and extensions that switch features off.
Does "Supported" mean the feature works fully?
It means the browser exposes it: the API exists, or CSS.supports() accepts the declaration. Parts of a feature can still be missing or faulty, and some APIs, such as WebGPU or Web Bluetooth, also need hardware or a permission when they are used. Test the critical path itself on real devices.
Does the check ask for camera, microphone or location access?
No. Permission states are read with the Permissions API, which reports granted, denied or "will ask" without showing a prompt, and no camera, microphone or location is opened. Camera, microphone and location are not listed at all, because this site turns them off for its own pages.
What do "Probably" and "Maybe" mean for a format?
They are the browser's own answers from canPlayType(): "probably" means it expects to play that format, "maybe" means it might, and no answer means it cannot. Only playing a real file proves playback. WebP and AVIF are tested by decoding a tiny embedded image.
Is anything sent to a server?
No. Every check runs in your browser, the image tests decode pictures embedded in the page, and the report is copied to your clipboard or downloaded, never uploaded.
Why do two browsers on the same computer give different results?
Each browser engine ships features on its own schedule, and settings, policies or extensions can turn a feature off in one browser but not the other. That is why the page tests the browser itself instead of looking up its name.
Technical notes
Feature detection follows the advice of MDN and the W3C and WHATWG specifications: test for the object or method a feature adds ('serviceWorker' in navigator, typeof WebAssembly.instantiate), never the browser's name. WebGL and WebGL 2 are tested by asking a canvas for a context, which is released at once.
CSS features are tested with CSS.supports(), defined in the CSS Conditional Rules specification: it answers whether the browser parses a declaration or a selector() — not whether every part of the feature is implemented. Cascade layers are detected through the CSSLayerBlockRule interface, because at-rules cannot be passed to CSS.supports().
Video and audio formats use HTMLMediaElement.canPlayType() from the WHATWG HTML Standard with the codec strings of RFC 6381, answering "probably", "maybe" or nothing. WebP and AVIF are decoded from 2 × 2 images embedded in the page, so no file is fetched.
Permission states come from navigator.permissions.query(), which returns granted, denied or prompt without asking the visitor anything; a name the browser does not know is reported as "Cannot be queried". Storage quota and persistence come from the StorageManager methods estimate() and persisted().
Limitations and methodology
Detection shows what the browser exposes, not how well it works: partial implementations, bugs and performance are not measured.
Camera, microphone and location permissions are not listed, because this site's Permissions-Policy turns them off on its pages; the API rows only show that the browser provides them.
Codec answers come from the browser and can depend on the operating system and hardware; only playing a real file proves playback.
Results describe this browser at this moment: an update, a setting or an extension can change them.
Security and privacy
Every check runs in your browser and nothing is sent to the Mutqan server or anyone else; the image tests decode pictures embedded in the page.
The report includes your user agent and preferences such as reduced motion. It goes only where you copy or download it — review it before you attach it to a public ticket.
References
- Implementing feature detection — MDNWhy code should test for the feature itself (an object, a method, CSS.supports()) rather than the browser's name, with the common detection patterns.
- CSS: supports() static method — MDNCSS.supports(): whether the browser supports a property and value, or a selector() condition, as defined in CSS Conditional Rules.
- HTMLMediaElement: canPlayType() method — MDNHow a page asks whether a media type and codec can be played, and what the answers "probably", "maybe" and the empty string mean.