How We Validate What We Tell You

Every technical claim on this site — whether an image is really HDR, whether your display can show it, whether a format is decodable in your browser — comes from executing a real check against real data, not from a hardcoded assumption or a filename guess. Where a check genuinely can't be run, the site says so, instead of quietly defaulting to a plausible-sounding answer.

Three-way status, not true/false

Booleans force a guess when the honest answer is "we don't know." Every capability and format check on this site instead reports one of a small set of states — typically SUPPORTED / PARTIAL / UNSUPPORTED / UNKNOWN for capabilities, or GOOD / WARNING / UNKNOWN for inspected file data. UNKNOWN shows up deliberately whenever a probe fails to run, times out, or has no verified test fixture to run against — it is never silently upgraded to a negative or a positive.

Metadata, pixels, and rendering are three different claims

A file can claim HDR in its metadata (a tag, a transfer-function code) without actually carrying HDR pixel data, and a browser can decode real HDR pixel data without your display ever rendering it any brighter than SDR. This site tracks and labels those as separate facts rather than collapsing them into one "is this HDR?" badge — see the Inspect tool's Color & HDR status panel, which reports format metadata, decoded-pixel analysis, and (where relevant) display capability as distinct fields.

Real byte-level parsing, not library trust

Format detection reads the actual bytes: JPEG marker segments, PNG chunk headers, ISOBMFF/AVIF boxes, WebP's RIFF container, ICC profile tag tables. Where a claim depends on a specific byte offset or structure, the parser that produced it is unit-tested against real fixture bytes — including at least one AVIF test built from a byte-verified fixture, with the expected box values documented and checked directly against the ground truth captured independently before the parser was written.

Live-probed capabilities, not a browser/version lookup table

The compatibility checker doesn't infer what your browser supports from its name or version string — it runs the actual operation (a canvas encode, an Image().decode(), a WebGPU device request) right now, in your browser, and reports what genuinely happened. Version-lookup tables go stale the moment a browser ships a change; an executed probe can't.

One specific bug this caught: an early version of the HDR-display probe could hang indefinitely if a decode call never settled (a real timing difference between a probe triggered by a click versus one running on initial page load). Rather than adding a guess, we added an explicit timeout that resolves to UNKNOWN — "this probe didn't finish" — never a fabricated UNSUPPORTED.

Computed thresholds, not eyeballed ones

Accessibility contrast ratios shown or relied on by this site's own design are computed using the WCAG relative-luminance and contrast-ratio formulas directly against the actual rendered color tokens, not judged by eye. Where a threshold needed real-world calibration — for example, the tolerance band used to classify an unusual ICC gamut as "in spec" versus "custom" — it was tuned against primaries measured directly from a real browser-generated sRGB profile, not a number chosen up front and left unchecked.

Round-trip validation before you can download

The Encode tool doesn't just produce a file and hand it to you — it decodes its own output back and checks the result before the download link is enabled. If that check fails, the download is blocked and the failure is shown, rather than handing over a file that merely looks correct.

Where this discipline has limits

This is a real, enforced practice, not a guarantee of perfection. It means claims are backed by an executed check at the time they were written and tested — not that every edge case across every browser and OS combination has been exhaustively covered. If you find a case where a status here doesn't match reality, that's a genuine bug worth reporting, not an expected outcome.