Reference
What a browser can't detect about your screen
Several popular screen-testing sites claim measurements that no web page can make. This is the full list of what is real, what is a judgement call, and what is simply not available to a browser, with the reason in each case.
Last updated
Every tool on this site is built against this reference. If a claim is not supported here, it does not appear on a tool page. That constraint costs us some impressive-sounding features, and it is the reason you can trust the ones that are here.
Not possible, at all
These need hardware a browser has no access to, or an API that does not exist. If a site tells you any of these from a web page, it is guessing or making it up.
| The claim | Why it is not possible |
|---|---|
| Automatic dead or stuck pixel detection | A page cannot read back the light your panel emits. There is no API for it and there never has been. Finding a bad pixel is done with your eyes on a clean field, which is all any pixel test actually provides. |
| Your true native panel resolution | Screen width multiplied by device pixel ratio is an estimate. Operating system scaling and browser zoom both change it, and macOS frequently renders at a scaled intermediate resolution that no browser API can see through. |
| Physical screen size, or pixels per inch | Not exposed to the web at all. A 24-inch and a 27-inch 1080p monitor are indistinguishable to JavaScript. Pixels per inch can only be worked out if you measure the diagonal and type it in. |
| Panel technology, OLED, IPS, VA, TN, Mini-LED | No API reports it. The "if black looks truly black it must be OLED" trick is a rough human heuristic, not a detection method, and it fails on a good VA panel in a dark room. |
| Brightness in nits, contrast ratio, or black luminance | These are photometric quantities. Measuring them means pointing a photometer at the screen in a controlled room. Nothing in a browser comes close, and a figure produced by a web page would be invented. |
| Colour accuracy, white point in kelvin, or gamut coverage percentages | All of these require a colorimeter or a spectrophotometer. A browser can send a colour to your display; it has no way of learning what came out the other side. |
| Response time in milliseconds | Pixel transitions can be demonstrated visually, which is what motion tests do. Timing them needs a photodiode sampling far faster than any browser can observe, which is why review sites use dedicated hardware. |
| Actual panel bit depth, 8-bit, 10-bit, or 8-bit with dithering | The colour depth a browser reports is almost always 24 and tells you nothing about the panel. Frame rate control, which makes an 8-bit panel behave like a 10-bit one, is invisible to software. |
| PWM frequency or flicker index | There is no API for backlight modulation. The only practical home method is a phone camera with a fast shutter, which is why a flicker test is a set of instructions rather than a measurement. |
| Your display maximum rated refresh rate | A browser observes the rate it is being given right now. It cannot see what your panel is capable of, which lives in the specification sheet and your operating system display settings. |
| Whether HDR is currently switched on | The dynamic-range media query reports capability. It tells you the browser and display can present high dynamic range, not that the operating system has it enabled or that what you are looking at is HDR content. |
| A refresh rate above what the compositor delivers | A page cannot paint faster than the browser compositor allows. If the compositor is capped at 60 frames a second, every timing measurement a page makes is capped with it. |
Genuinely measurable
These work, and the results can be stated as fact. Most of them are more useful than the invented ones, because they tell you about the thing you can actually change.
| Capability | How |
|---|---|
| Fill the screen with an exact colour | A CSS background on a fullscreen element. The basis of every pixel, bleed, uniformity and burn-in test. |
| Observed refresh rate | The median of requestAnimationFrame timestamp intervals. Accurate to within about a hertz given enough samples. |
| Dropped and irregular frames | Outliers against that median. Genuinely reveals stutter and jank. |
| HDR capability | The dynamic-range media query. Capability only, never current state. |
| Colour gamut capability | The color-gamut media query, in sRGB, P3 and Rec.2020 buckets. |
| Wide-gamut rendering | CSS color(display-p3 …) genuinely paints outside sRGB on a capable display. |
| Maximum touch points | navigator.maxTouchPoints, plus the peak actually delivered during a test. |
| Multi-touch tracking, drawing and drift | Pointer Events, which unify mouse, touch and pen in one code path. |
| Input sampling rate | getCoalescedEvents returns every sample the operating system delivered between frames, which is the real input stream rather than a frame-rate-capped one. |
| Screen size in CSS pixels and device pixel ratio | Reliable as reported values. What they mean is where the care is needed. |
| Keeping the screen awake | The Screen Wake Lock API, over HTTPS, on current browsers. |
| Working with no network at all | A service worker precaching the whole toolset. These tests need no server. |
Real, but it depends on you
These sit in between. The pattern is exact and the technique is sound, but the answer depends on your eyes, your room, or your hardware in ways no page can account for. Each of these is labelled as such on the tool that uses it.
| Technique | What it is worth |
|---|---|
| Freeing a stuck pixel | Rapid colour cycling works often enough to be worth trying and cannot fix a dead pixel. Reported success rates vary between roughly 60 and 80 per cent depending on who is reporting. |
| Clearing image retention | Full-field cycling clears temporary retention. It cannot reverse permanent burn-in, and nothing else can either. |
| Gamma estimation | The alternating single-pixel line technique works, but only at exactly 100 per cent browser zoom and whole-number display scaling. Anywhere else the pattern is resampled and the answer is wrong. |
| Banding and bit-depth impression | Precisely drawn gradients make banding visible. GPU dithering, driver settings and colour management all interfere, so no bit-depth verdict can follow from it. |
| Screen tearing | Browsers normally composite with vertical sync, so this reveals compositor and driver misconfiguration rather than reproducing in-game tearing. |
| Viewing angle, sharpness, uniformity, bleed and glow | Entirely human judgement against a known pattern. The tool provides a correct pattern and teaches you what to look for. |
| Colour temperature comparison | sRGB approximations of different white points shown side by side. A comparison aid, not a measurement of your panel white point. |
Why this matters
Two reasons, one practical and one about trust.
The practical one: a fabricated number sends you in the wrong direction. If a site tells you your contrast ratio is 1000:1 and your blacks look grey, you will start doubting your eyes, when the actual cause is almost certainly an RGB range mismatch you could fix in a settings menu in thirty seconds. Knowing which parts of a result are measured and which are your judgement is what makes the result usable.
The trust one: if a tool claims something it cannot do, you have no way to know which of its other claims are real. A site that says it automatically scans for dead pixels has told you something demonstrably untrue on its front page. That is worth remembering when it also tells you your panel is 10-bit.
What to use instead
- For measured display specifications, use hardware review sites that publish their methodology and their equipment. They measure brightness, contrast, response time and colour accuracy with instruments, on your exact model.
- For motion and refresh rate research, go to Blur Busters and TestUFO. The pursuit-camera method for photographing motion the way your eye sees it is theirs.
- For calibration test images, Lagom LCD tests remains the reference set, and has been for twenty years.
- For colour accuracy, there is no substitute for a colorimeter. Entry-level units are affordable and the software does the rest.
- For how the web platform behaves, MDN documents every API named on this page, including which browsers support them.
Found something wrong?
If a browser gains a capability listed here as impossible, or if something on this page is inaccurate, tell us and it will be corrected and noted in the changelog. The methodology page covers how the measurable items are implemented.