Device diagnostics research

Why a Dead-Pixel Test Can Be Wrong in Both Directions

A dead-pixel test sounds like the simplest possible tool: fill the screen with red, green, blue, white, and black, and look. The browser does not control the final display pipeline, however, and five separate confounders sit between the color the page requests and the light the panel emits. Our evidence file records each one so the tool can state what it can and cannot conclude.

By BeanNest Studio Reviewed September 20, 2026

What this guide helps you decide

A screen shows a solid color and the user looks for a spot. What can make that test report a defect that is not there, or miss one that is?

This research explains the display-pipeline confounders that affect a browser dead-pixel test, using a derived definition set. It does not certify any panel and does not diagnose any specific display.

Try it on the anchor product: BeanNest Tools /device/.

Confounder one: pixel-ratio scaling

A test block sized in CSS pixels can cover a fractional number of device pixels when the device pixel ratio is not an integer, or when a zoom level is active. A stripe that should be one device pixel wide may land across two, which changes what the user is inspecting.

Confounder two: subpixel stripe order

Many panels build each pixel from separate red, green, and blue emitters in a fixed horizontal or vertical order, and that order varies by panel. A one-device-pixel line intended to illuminate one subpixel can illuminate a different one than expected.

Confounder three: color management

An ICC transform can shift a nominally pure channel value before it reaches the panel. The page asked for full red; the pipeline may deliver a slightly different value. Assessing a subpixel defect against an inexact reference is unreliable.

Confounder four: panel response and overdrive

Fast color changes can produce transient inverse ghosting, especially on panels using response-time overdrive. A user switching quickly between test colors can see a temporary artifact and misread it as a stuck pixel.

Confounder five: compression and capture

If the test is viewed through screen sharing, a remote session, or a video call, the image is compressed. Compression can introduce block artifacts that look like pixel defects and can also hide a real one.

The claim that survives

A browser test can present candidate locations for a human to inspect and can confirm that a location looks the same across several colors. It cannot certify a panel defect, because it does not control the display pipeline. Our evidence file records the five confounders and the honest claim side by side.

Why a solid colour test is still useful

Despite five confounders, filling the screen with a known colour and asking a human to look remains effective for gross defects. A permanently black or permanently bright spot is visible against any uniform field, and a human observer is far better than an automated check at distinguishing a real defect from an artifact. The tool's value is in presenting a clean field and letting a person judge, not in producing a verdict.

How to reduce scaling error

Displaying the test at the screen's native resolution with browser zoom at one hundred percent removes most pixel-ratio error, because one CSS pixel then maps to an integer number of device pixels. The analyzer cannot enforce this, but the guide can state it, and a user who follows it avoids the fractional-coverage problem entirely. That is a practical mitigation for a structural confounder.

Why colour management is hard to defeat from a page

A page can specify exact channel values, but it cannot prevent the operating system or the display from applying a profile. A monitor calibrated for photography deliberately shifts colours away from the raw values. A test that assumed its red was full red would then be comparing against a reference that the pipeline never delivered, which is why the guide treats the rendered value as unknown.

What overdrive artifacts look like

On panels using response-time compensation, a rapid transition between very different colours can briefly overshoot, producing a faint inverse image of the previous content. A user cycling quickly through test colours can see that and read it as a stuck pixel or a ghosting defect. Slowing the transition and waiting before judging is the practical mitigation, and the guide states it as such.

Why a browser cannot control the display pipeline

A page specifies colours in a document colour space, and between that specification and the emitted light sit scaling, subpixel mapping, colour management, and panel response. Each stage can alter what a user sees without the page being able to detect or prevent it. A test that assumed its specified colour reached the panel would be reasoning about a pipeline it does not own, which is why the guide treats the rendered value as unknown.

How the five confounders interact

The confounders are not independent. Fractional pixel coverage combined with subpixel stripe order can illuminate an unexpected emitter, and colour management can shift the value that reaches it. A user observing a spot is therefore looking at the combined result of several stages, which is why the guide lists them together rather than treating each as a separate diagnosis. The practical mitigation is to control the ones a user can control and judge the rest with caution.

What a human observer adds that automation cannot

A person can distinguish a persistent defect from a transient artifact, can notice that a spot moves when the viewport changes, and can recognise a compression block from a remote session. An automated check can compare pixels but cannot make those judgements. That is why the tool's value is in presenting a clean uniform field and letting a person inspect it, rather than in producing a verdict.

How to reduce the error a user controls

Use native resolution with browser zoom at one hundred percent, pause between colour changes, judge from a comfortable distance, and avoid remote sessions or screen sharing. Each step removes one confounder or its interaction with another. None of them makes the test authoritative, and together they make an observation much more likely to reflect the panel rather than the pipeline.

What a defensive display check should claim

It should claim that a uniform field was presented and that a human reported what they observed. It should not claim that a panel is defective, that a number of pixels failed, or that a warranty condition is met. The first is supported by the tool's behaviour and the second is not, and stating the boundary is what keeps a useful diagnostic from becoming an unsupported certification.

Why a false negative is as likely as a false positive

A real defect can be hidden when the test colour happens not to reveal it, when the spot falls on a fractional pixel and is smeared across two, or when compression in a remote session removes it. A user looking for a defect after a test reported nothing may therefore stop looking too early. The guide treats both directions as equally likely rather than assuming the tool errs on the side of caution.

How to make an observation more reliable

Check the same location against several colours, move the window slightly to see whether the spot moves with the content or stays with the screen, and judge from a comfortable distance rather than close up. A spot that stays with the screen across colours and window positions is more likely real, while one that moves with the content is a rendering artifact. Those checks cost nothing and materially improve the observation.

What the test colour set is for

Black, white, red, green, and blue together exercise each subpixel channel as well as the combined states. A stuck subpixel may be invisible against one colour and obvious against another, so running the set rather than a single colour is what makes the check useful. The evidence file records the five colours and the confounders that can affect each of them.

Why certification is out of scope

A panel defect determination has warranty and support consequences, and a browser test controls none of the pipeline stages that would make such a determination reliable. The guide therefore supports a candidate location for human inspection and explicitly declines to support a defect certification. That boundary protects a user from acting on a claim the method cannot substantiate.

First-party evidence and provenance

How we checked this

We derived the mechanism set from documented protocol limits, Web platform scheduling behaviour, and the electrical model of a keyboard matrix, then encoded each constant with its reason in a generator script in this repository. The definitions file is regenerated by running that script. For this guide we enumerated the display-pipeline stages that sit between a requested test color and the emitted light, and recorded each confounder that can produce a false positive or false negative.

Method: We derived the mechanism set from documented protocol limits, Web platform scheduling behaviour, and the electrical model of a keyboard matrix, then encoded each constant with its reason in a generator script in this repository. The definitions file is regenerated by running that script.
Environment: Node.js on a desktop workstation. The evidence is a definition set with recorded reasons, not a hardware measurement on a specific device.
Captured: September 20, 2026
Reviewed by: BeanNest Studio

Repository evidence artifacts:

tools/research-evidence/device/definitions-2026-09-20.json
tools/research-evidence/device/README.md