HTML5 / CSS3 Feature Detection

Features

• Sixty-plus checks in four groups: HTML elements and attributes, CSS, browser APIs, media formats
• CSS is measured with `CSS.supports()` — more reliable than writing an element and reading its style, which misreports when defaults coincide
• Media formats are measured with `canPlayType()`, showing what it returns (probably / maybe)
• WebGL 2 reports the renderer version alongside
• Filter to only the unsupported rows — when diagnosing an environment, those are the whole story
• Copy a plain-text report in one click, with the UA at the end (the first thing anyone asks for)
• Unsupported rows expand with a sentence on what the check measures
• Everything is local: no requests, no cookies

How to use

1. Open the page; the checks run immediately
2. Read the number at the top — the share supported on this machine
3. Switch to “Only unsupported”; those are the ones that need work
4. Press “Copy report” and paste it into a ticket or a chat

FAQ

Why not just look at a compatibility table?

Because a table answers a different question. It says “supported since version X”, while real support also depends on the operating system (the same browser version differs across platforms), the device (low-end machines disable APIs), user settings (battery savers, privacy settings, enterprise policy), and the context you are in (`crypto.subtle` only exists over HTTPS, and so does Service Worker). Tables are for planning; “does it work on this machine right now” can only be measured. The two do not conflict — just do not use one as the other.

Can I use the results as compatibility evidence?

Yes, and it is more accurate than a table — but only for this browser on this machine. The way to use this tool is not “decide whether to adopt a feature” but to write feature detection into your code (`if (CSS.supports(...))`, `if ("showPopover" in HTMLElement.prototype)`) and let each browser choose its path. The tool’s value is knowing in advance which paths need planning, and diagnosing “why does this do nothing here”.

Why not show my browser name and version?

Because judging capability from a name and a version number is wrong. User-agent strings can be spoofed, the same version behaves differently across operating systems, and there is no dependable mapping from a version number to a set of features. The correct move is to detect the capability itself (what this tool does), not the identity — which is the technical reason behind the old rule that feature detection beats UA sniffing. The UA appears in the report only so people know where the results came from.

Something shows as unsupported but I think it should work?

Read the note under that row first. The usual causes: HTTPS is required (`crypto.subtle`, Service Worker, camera and microphone, clipboard writes), permission is required (geolocation, notifications), platform-specific (the File System Access API is Chromium-only), or disabled by settings or policy (storage in private mode, WebGL under enterprise policy). None of those mean “the browser cannot do it”, only “not here, not now” — different judgement, different fix.