What it does
When this page opens, a script runs about 60 small checks against your current browser and lists each feature as supported or not. Results are grouped into JavaScript language, CSS, graphics, media and codecs, storage, networking, device APIs, security, and interface features, with a count of supported features in the summary at the top.
Each check is a question the browser can answer without doing anything visible. For JavaScript that usually means testing whether something exists, such as structuredClone or Promise.withResolvers, or whether newer syntax is accepted, such as a regular expression with the v flag. CSS rows go through CSS.supports(), which reports whether the style engine understands a property, value or selector such as :has(). Codec rows use the browser's own answers from canPlayType() and Media Source checks.
No check opens a permission prompt, starts a device picker or sends anything over the network. For hardware APIs such as Web Bluetooth, WebUSB or Web NFC, supported means the browser exposes the interface, not that a device is connected or allowed.
How to use it
- Open the page in the exact browser, profile and device you want to know about. The checks start by themselves.
- Read the summary count, then scan each group for rows marked not supported.
- In the media group, note any codec shown as partial. That is the browser answering maybe instead of probably.
- Press the copy-as-text button to put the whole list on your clipboard.
- Paste it into the bug report, ticket or chat thread, and add the browser version and operating system if they are not already there.
Test in the same window where the problem happens. Extensions, enterprise policies and experimental flags can switch individual features on or off.
Two rows describe the page as much as the browser: secure context depends on how the page was loaded, and cross-origin isolation on headers the server sends, so another site can get different answers for those two.
Use cases
- Support tickets. A customer reports that saving a large file does nothing. Ask them to open this page and paste the copied list; a missing Origin Private File System or Fetch streams row can settle it in one reply.
- Video that will not play. A clip plays on one laptop and shows a black frame on another. Compare the HEVC and AV1 rows on both; a no or partial answer is a sign to also serve an H.264 or VP9 version.
- Deciding what to ship. Before relying on
:has(), container queries or CSS nesting, open the page on the oldest browsers your users still run, including kiosks and smart TVs. - In-app browsers. Links tapped inside chat and social apps often open in an embedded web view. Opening this page that way shows what the view supports, which can differ from Safari or Chrome on the same phone.
- Hardware projects. Before telling users they can flash a microcontroller or configure a keyboard from a web page, have them check the Web Serial, WebUSB and WebHID rows; some major browsers lack these interfaces entirely.
Feature detection versus user-agent sniffing
The older habit was to read the user-agent string and infer capabilities from the browser name. That breaks in predictable ways. Chromium-based browsers share most of their user-agent text. Chrome on an iPhone carries a CriOS token but normally renders with WebKit, so for most rows here it behaves like Safari. Chrome has also frozen parts of the version and platform detail in its string, and anyone can change the string in a few clicks.
Feature detection asks the running browser instead, which also makes progressive enhancement simple: build a baseline that works everywhere, then add the better path only where the check passes.
if ('share' in navigator) {
shareButton.hidden = false; // native share sheet
} else {
copyLinkButton.hidden = false; // plain fallback
}@supports (container-type: inline-size) {
.card-list { container-type: inline-size; }
}Codecs work the same way. A player can call video.canPlayType('video/mp4; codecs="av01.0.05M.08"') and fall back to an H.264 source when the answer is an empty string, which is how the browser says no. The only other answers are maybe and probably.
Why the same browser can answer differently
Hardware and operating system
Many rows depend on more than the browser build. HEVC playback often needs a hardware decoder or operating-system codec support, so the same browser version can disagree on two laptops. Safari reports AV1 only on Apple devices with an AV1 hardware decoder. WebGPU has shipped on some operating systems before others, and a browser can switch WebGL off when the graphics driver is on its blocklist. Some open-source browser builds leave out licensed codecs such as H.264 and AAC.
Secure contexts
Many APIs exist only in a secure context: pages served over https, plus local addresses such as http://localhost and http://127.0.0.1. Service Workers, the asynchronous Clipboard API, Web Authentication, Web Share, Screen Wake Lock, WebGPU and the device APIs are in this group. Load the same site over plain http on a LAN address and those objects are absent rather than blocked, so a feature that works on localhost can vanish on a test server. window.isSecureContext reports the state. Cross-origin isolation, which unlocks SharedArrayBuffer, also requires Cross-Origin-Opener-Policy and Cross-Origin-Embedder-Policy response headers.
The list is also a fingerprint
Because results vary by browser, version, operating system and hardware, the full pattern of answers narrows down which setup a visitor has. Fingerprinting scripts run the same kind of checks for that reason, next to canvas rendering and installed fonts. This page runs its checks locally and sends nothing, and iseeu.cc keeps no request logs, but any site can run equivalent code without showing you the result. Before pasting the list into a public issue tracker, treat it like any other system detail you share.
Frequently asked questions
Does this page ask for camera, Bluetooth or notification permission?
No. Every check only asks whether an API exists or whether the browser claims support for something. Nothing calls a method that would open a permission prompt or a device chooser, and no data leaves your browser. The Notifications row, for example, checks that the API is present; it does not ask to show you notifications. iseeu.cc also sets no cookies and keeps no request logs.
A feature shows as supported, so why does it still fail on my site?
Supported here means the browser exposes the API or says it understands the syntax. Real use can still fail: your site may be loaded over plain http and lose secure-context APIs, a permission may be denied, a policy may block a device, or WebGPU may find no usable graphics adapter. Codec rows reflect what the browser claims, and an unusual profile or resolution can still fail to decode.
What does partial mean in the codec rows?
The canPlayType method never answers yes. It returns probably when the browser is fairly confident it can play the format, maybe when it recognizes the format but cannot be sure without trying, and an empty string for no. This page shows maybe as partial. Treat a partial result as a reason to run a real playback test with your own file before relying on that codec.
Why does my colleague see different results with the same browser version?
Several rows depend on the operating system and hardware rather than the browser version. HEVC and AV1 often rely on hardware decoders, WebGPU availability differs by platform and graphics driver, and some builds ship without licensed codecs. Extensions, enterprise policies, experimental flags and private windows can also change individual answers. Comparing the two copied lists side by side is the quickest way to find the difference.
Why do some features disappear when a site is opened over http?
Browsers expose many newer APIs only in secure contexts, meaning pages loaded over https or from local addresses such as localhost. On a plain http page, objects like navigator.serviceWorker and navigator.clipboard are simply undefined. That is deliberate: these APIs reach devices, credentials or long-lived background code, and an unencrypted page could be altered in transit. Serve test environments over https to see the same behavior as production.
Can this list be used to identify me?
On its own, a list of supported features describes your browser, operating system and hardware rather than you. Combined with other signals, such as screen size, installed fonts and canvas output, it adds to a browser fingerprint that can help recognize a returning visitor. This page runs the checks locally and sends nothing, but other sites can run the same tests quietly, so the exposure lies in the combination rather than in this list alone.
Should I check the user-agent string instead?
For deciding whether to use a feature, no. User-agent strings are shared between Chromium-based browsers, reduced in detail by Chrome, easy to change, and misleading on iPhones, where Chrome and Firefox normally render with WebKit. Testing the feature directly gives the answer for the browser that is actually running. The user-agent string is still useful in a bug report for recording the exact browser version.
Detection reports what the browser exposes or claims. A feature can still be disabled by policy, missing hardware or a denied permission when a site actually tries to use it.