A dead pixel test's accuracy is bounded by what the tool actually does: it requests one of eight specific sRGB color values from the browser and lets your eyes compare that field against your expectations. The W3C CSS Color specification defines the eight values, not the light your panel emits, so accuracy in this context means the test reliably shows the requested stimulus, while everything between the browser and the panel (color management, HDR mode, gamut, viewing angle, scaling, local dimming, subpixel layout) still decides what your eyes actually receive. A point that looks wrong against one field may look fine against another, which is why a checklist of eight solid colors is more useful than a single white screen. Knowing where that boundary sits, between the documented stimulus and the unmeasured panel, is what makes a visual check trustworthy as a first pass, and it explains why the test itself never claims to certify a pixel as dead.
What "accuracy" means in a dead pixel test
People searching for dead pixel test accuracy are usually asking two different questions. The first is whether the test itself is faithful to a documented specification. The second is whether what you see on the screen actually represents your panel.
For the first question, the answer is yes for any tool that publishes its fixture. A reliable test renders an immutable set of solid CSS color values, names them clearly on screen, and lets you move through them with predictable controls. The Dead Pixel Test uses exactly eight values taken from CSS Color Module Level 4: black #000000, white #ffffff, red #ff0000, lime #00ff00, blue #0000ff, cyan #00ffff, magenta #ff00ff, and yellow #ffff00. The current pattern's name, position, and exact hex value are printed on a progress line so you can confirm what you are supposed to be looking at. The W3C defines the values; the MDN named-color reference documents them. There is no theme guesswork and no approximate palette.
For the second question, accuracy depends on the panel and the pipeline. The browser asks the operating system for a CSS color; the operating system forwards it through a color-managed pipeline; the GPU sends it to the panel; and the panel applies its own gamut, brightness, and image processing before producing light. Any link in that chain can shift what reaches your eye, which is why a dead pixel test is a precise stimulus generator and an imprecise measurement device.
The eight sRGB color fields and why each one is included
Different pixel faults show up best against different fields, and that is the entire reason a checklist exists. The test cycles through eight patterns in this order:
| # | Color | Hex value | What it helps reveal |
|---|---|---|---|
| 1 | Black | #000000 | Pixels stuck bright, backlight bleed, always-on subpixels |
| 2 | White | #ffffff | Pixels stuck dark, dim subpixels, dead subpixels |
| 3 | Red | #ff0000 | Red subpixel faults and contamination from neighboring channels |
| 4 | Lime | #00ff00 | Full green-channel subpixel faults (the CSS named color lime, not the darker #008000 named green) |
| 5 | Blue | #0000ff | Blue subpixel faults and panel-specific artifacts |
| 6 | Cyan | #00ffff | Combined green and blue channel faults |
| 7 | Magenta | #ff00ff | Combined red and blue channel faults |
| 8 | Yellow | #ffff00 | Combined red and green channel faults |
The sequence is not decorative. It covers three single-channel primaries plus white and black, then three two-channel combinations. A red subpixel that is stuck on will light up the black field and stay visible against cyan and blue, while a red subpixel that is stuck off will show up as a dark dot on the white field and on red, yellow, and magenta. Different combinations produce different visible signatures, so stepping through all eight gives the visual check more reach than a single full-screen color ever could.
The values themselves are fixed by the CSS Color specification. The W3C named-colors list defines green as #008000, which is why the test labels its full-green pattern as lime at #00ff00 instead. That distinction matters for accuracy: if the fixture were using #008000, the green channel would only be partially exercised and a full-green-channel fault could be hidden.
Run a dead pixel test with full accuracy
- Clean only the outer display surface using the manufacturer's safe procedure before opening the test. A speck of dust will read as a "mismatch" long before any panel issue shows up.
- Open the Dead Pixel Test and select Start fullscreen test. Fullscreen is only a browser request from the Start button; if the browser denies it, the in-page panel still cycles through all eight patterns.
- Move through the eight fields with a click, the Space key, or the arrow keys. The progress line always shows the current pattern name, its index, and the exact hex value, so you can confirm what you are supposed to be looking at.
- Inspect several regions on every field, including the edges and corners, not just the center. Faults can hide in the corner where your gaze does not usually linger.
- Note any point that stays the same color across several different fields. A stationary dot that contrasts with each new background is the strongest visual signal.
- Press Escape or exit fullscreen through the browser's normal control. The test does not disable the Escape key or force kiosk mode.
- If you find a stationary mismatch, check manufacturer diagnostics and warranty policy before any repair decision. The visual check is a starting point, not a verdict.
Factors that change what you see on the panel
The test is accurate about what it requests, and inaccurate about claiming to certify your monitor. The gap comes from the pipeline:
- Color management and ICC profiles can remap the requested sRGB value into a panel-native color.
- HDR mode, panel gamut (wide-gamut panels often render sRGB as more saturated), and hardware calibration all change the displayed hue.
- Subpixel layout, scaling, and image enhancement (sharpening, dynamic contrast) can make a uniform field look subtly textured.
- Local dimming and burn-in protection can dim or shift large solid areas, which can hide or fake a defect.
- Viewing angle and ambient light change contrast and color perception in ways the CSS value cannot account for.
- Cable faults, GPU output quirks, and remote-display compression can introduce artifacts that have nothing to do with the panel itself.
The W3C CSS Color specification defines what the browser asks for, not what your display emits. The test therefore identifies the requested stimulus, not a measured color from the panel.
What a mismatch does and doesn't prove
A visible mismatch is not automatically a dead pixel. Several non-panel causes can produce the same symptom:
- Dust, fingerprints, and screen protectors sitting on the outer surface
- Reflections and glare that move as you change angle
- Image retention from a previous image
- Stuck subpixels that are partially, not fully, faulty
- Browser zoom, rendering, or scaling artifacts
- GPU output, cable faults, or remote-display compression
A screenshot is only a partial tool for separating causes: a defect inside the panel usually does not appear in a screenshot at all, while a rendering or content-generation bug might. If a stationary dot does not show in a screenshot but is visible to your eye on the actual panel, that leans toward a hardware issue. If it does show in the screenshot, the cause may be further up the pipeline.
If the display shows spreading damage, electrical symptoms, impact damage, or safety concerns, stop using it and follow qualified manufacturer guidance. Do not apply pressure, tap, heat, or rapidly flash the panel in an attempt to "unstick" a pixel, and do not install untrusted pixel-fixing software. The test deliberately uses static fields and provides no strobe, force instruction, or repair promise for that reason.
When to escalate from a visual check to manufacturer diagnostics
Manufacturer diagnostics and warranty policy are the right authority for repair or replacement decisions. The visual check is a triage step that can confirm a fault is present, narrow down which channel is affected, and tell you whether the symptom is consistent across multiple fields.
If a stationary mismatch shows up on every field you test, the next step is the manufacturer's built-in diagnostics. Most operating systems and monitor OSDs include a self-test pattern generator that bypasses the browser pipeline entirely. Run that. If the manufacturer's pattern still shows the fault, the panel itself is implicated; if it does not, the cause is somewhere between the browser and the panel.
For more on the inspection workflow itself, see Dead Pixel Test and Fix: Inspect the Display First. The visual check is the start of that workflow, not the end.