Methodology

Nothing here is proprietary. Every technique below is standard web platform work, and the point of writing it down is so you can check it rather than take our word for it. If you think something is wrong, say so.

Colour fields

Solid test fields are painted as a CSS background colour on a fullscreen element, with no filter, opacity, blend mode or transform applied anywhere in the chain. A white screen test renders sRGB 255, 255, 255 in both the light and dark themes, because the test surface is deliberately excluded from theming.

The one exception is the dim control on the colour tools, which applies a CSS brightness filter. It sits at 100 per cent by default, at which point no filter is applied at all, and the page displays a warning whenever it is not at 100 per cent. That warning exists because a dimmed field is no longer the value you asked for, and judging a display against it would be a mistake.

Gradients and patterns

Ramps, step wedges and near-black ladders are drawn on a canvas, one column or patch at a time, at explicit code values. They are not CSS gradients. Browsers may dither a CSS gradient, and dithering hides precisely the banding a gradient test exists to reveal, so using one would quietly defeat the test.

Grey levels are code values rather than shares of emitted light. A field described as 50 per cent is code value 128, which produces roughly 21 per cent of maximum luminance because the sRGB transfer function is close to a power of 2.2. Where that distinction changes how you should read a result, the tool says so.

Refresh rate: median, not mean

The refresh rate test collects requestAnimationFrame callback timestamps for a fixed duration, discards the first five intervals as warm-up, and takes the median of the remainder. The rate is 1000 divided by that median.

An average would be wrong, and not subtly. One 200 millisecond pause, a garbage collection, a background process, a browser extension, in a five second run at 144 Hz pulls the mean down far enough to report a completely different mode. The median ignores a minority of outliers, so a stall shows up where it belongs, in the dropped-frame count, instead of corrupting the headline number. There is a unit test that asserts exactly this: a synthetic 144 Hz series with three injected 200 millisecond stalls must still report 144.

The measured figure is snapped to the nearest standard mode only when it is within 1.5 per cent of it. Outside that tolerance the raw number is shown and the page says it does not match a standard mode, because a display that is genuinely running at an unusual rate is information, not an error to be rounded away.

A run aborts if the tab is hidden. Background tabs are throttled to roughly one frame a second, which would produce a nonsense result, so the page tells you the run was void rather than reporting it.

Frame pacing

The frame-time graph holds a rolling buffer of the last 300 intervals. Bars are coloured against the median: green within 20 per cent, amber within 50 per cent, red beyond. The 1 per cent low is the mean frame rate across the slowest one per cent of frames, which describes the worst moments rather than the typical one and correlates far better with whether motion feels smooth.

Motion

Every moving object derives its position from elapsed time: x = elapsed × pixelsPerSecond ÷ 1000, rather than adding a step each frame. A per-frame increment would make the object travel at a different real-world speed on every display, so results could not be compared between machines. Time-derived motion crosses the screen in the same number of seconds at 60 Hz and at 240 Hz.

Objects are moved with translate3d on a promoted layer so the compositor handles them. Animating a layout property such as left would put layout work inside every frame and add its own stutter to the thing being examined.

No motion test produces a millisecond figure, because a browser cannot honestly produce one. Pixel response is measured with a photodiode; perceived motion blur is measured with a pursuit camera. Both are documented by Blur Busters, whose research underpins this whole area.

Pointer input

Touch and stylus tools use Pointer Events rather than touch events, so mouse, touch and pen run through one code path and each contact can be followed by its pointer identifier.

Sampling rate is taken from getCoalescedEvents, which returns every sample the operating system delivered between frames. Timing raw pointermove events would measure the frame rate rather than the input device, since that event fires at most once per frame. Where a browser does not support coalesced events, the reading is marked as degraded and is never snapped to a standard polling rate, because a frame-capped number dressed up as a polling rate would be worse than no number.

Pressure is displayed only when a device reports values that actually vary. Most touchscreens report a constant, and presenting a constant as a force reading would be inventing a measurement.

Device-pixel rendering

Patterns that depend on single physical pixels, gamma, inversion, fine lines, are drawn on a canvas sized to cssWidth × devicePixelRatio with image smoothing disabled.

When the device pixel ratio is not a whole number, which happens with 125 or 150 per cent display scaling and with browser zoom, single-pixel patterns get resampled and the result is meaningless. In that situation the affected tools refuse to show a result and explain why, rather than showing a number that looks authoritative and is wrong.

Capability detection

HDR and colour gamut come from the dynamic-range and color-gamut media queries. There is a trap here that is easy to miss: a media feature a browser does not understand evaluates to false, which is indistinguishable from a genuine negative. Every query is therefore tested with matchMedia(...).media !== 'not all' first, and an unsupported feature is reported as "not reported" rather than as a negative result. There is a unit test for that too.

The wide-gamut swatches use the hidden-swatch technique: a shape painted in a Display P3 primary sits on a background painted in the closest sRGB primary. On an sRGB display both resolve to the same pixel values and the shape is invisible; on a wide-gamut display it appears. The three primaries are not equally useful for this, converting each P3 primary into P3 coordinates and comparing shows green separating by about 117 steps out of 255, red by 51, and blue by only 10, because the sRGB and P3 blue primaries sit almost on top of each other. The page ranks them in that order and says so, rather than letting a blank blue square read as a failure.

Wake lock

Long-running tools request a screen wake lock so the device does not sleep mid-run. The lock is released by the browser whenever the document is hidden, so it is re-acquired on visibilitychange. Where the API is unavailable or refused, the tool says the device may sleep instead of failing silently.

What we do not do

No analytics, no third-party scripts and no tag manager. One typeface is served from this domain rather than a font network. Nothing you do here is transmitted anywhere, because there is no server component at all, the whole site is static files. The only browser storage used is a preference for your theme, your last-used colour, and your guided-check answers, all of which stay on your device and are described on the privacy page.

Testing

The measurement engines have unit tests covering the cases most likely to produce a confidently wrong answer: outlier rejection in refresh rate, snapping tolerance, aspect ratio reduction, pixels-per-inch arithmetic, polling rate derivation, colour space conversion, and the unsupported-media-feature trap. A build-time scan also checks every generated page against a list of forbidden claim patterns, so a sentence like "your brightness is 350 nits" fails the build rather than reaching you.

The companion page to this one is what a browser cannot detect, which covers the other half: the measurements that are not available at any price.