A dead pixel test for mobile is a visual screen check that fills the display with eight solid colors so you can look for points that do not match the surrounding field. For a phone or tablet, the practical goal is not to label a spot from one glance; it is to see whether an apparent mismatch stays in the same place as the colors change. The Dead Pixel Test gives you a large focusable panel that runs black, white, red, full green, blue, cyan, magenta, and yellow in a defined sRGB sequence. You can request a larger browser presentation, tap or click to move, press Space, or use arrow keys, and read the current pattern, position, and exact hexadecimal CSS value from the progress line. Nothing is uploaded: no screenshot, display identifier, color profile, observation, or navigation history leaves the page. This check can help you describe a repeatable visual symptom, but it does not measure the panel's physical light output or diagnose a failed subpixel. If a spot persists across several fields, leave the test normally and use the phone or tablet maker's diagnostic tools and warranty policy before requesting repair.
What the mobile test actually checks
The page provides a controlled visual stimulus rather than a hardware meter. One large panel displays one exact CSS color at a time, while the progress line identifies the pattern, its position in the eight-color sequence, and its hexadecimal value. That lets you confirm which field you are viewing and repeat the inspection consistently. The tool visually compares points with their surroundings; it does not sample individual pixels or return a pass-or-fail hardware result.
The requested CSS color and the light emitted by a phone or tablet are not guaranteed to be identical. Browser color management, operating-system profiles, HDR modes, panel gamut, scaling, subpixel layout, viewing angle, local dimming, image enhancement, burn-in protection, and hardware calibration can all affect appearance. The page identifies the requested stimulus, not a measured color from the display.
| Field | Exact CSS sRGB value | What to compare visually |
|---|---|---|
| Black | #000000 | Points that remain unexpectedly bright |
| White | #ffffff | Points that remain dark or fail to match the field |
| Red | #ff0000 | A missing or unexpected red contribution |
| Full green, also named lime | #00ff00 | A missing or unexpected green contribution |
| Blue | #0000ff | A missing or unexpected blue contribution |
| Cyan | #00ffff | A missing or unexpected green or blue contribution |
| Magenta | #ff00ff | A missing or unexpected red or blue contribution |
| Yellow | #ffff00 | A missing or unexpected red or green contribution |
The fixture is checked against the W3C CSS Color Module Level 4 named-color reference and the MDN named-color reference. In particular, #00ff00 is CSS lime, the maximum value of the green channel; it is not the darker named color green, #008000. These references define CSS color values, but they do not certify the physical output of a particular mobile display.
Run the check on a phone or tablet
- Clean the outer surface safely. Follow the display manufacturer's recommended cleaning method before testing. Clean only the outside of the screen and avoid applying pressure to a suspected defect.
- Open the page in your mobile browser. Place the phone or tablet on a stable surface where you can inspect it without touching the display. Leave browser zoom at its normal setting, because zoom artifacts can resemble panel problems.
- Select Start fullscreen test. This direct action asks the browser for a larger presentation of the color panel. It does not change your brightness, display settings, or other device controls. If the browser refuses the request, continue with the in-page panel as described below.
- Inspect the first field from edge to edge. Look for points that differ from the surrounding color rather than focusing only on the center. On black, note unexpected bright points; on white, note points that remain dark. Pay particular attention to the edges and corners.
- Move between patterns. Tap or click the panel, press Space, or use the arrow keys. Forward and backward navigation wrap around the sequence. A touch-only phone does not require a physical keyboard.
- Review all eight fields. Check black, white, red, full green, blue, cyan, magenta, and yellow. At each change, pause long enough to scan the center, edges, and corners while watching the progress line for the exact pattern and hexadecimal value.
- Note stationary mismatches. Treat a point as a candidate symptom only when it remains in the same physical location across several fields. A spot visible against one color but absent against another is not, by itself, proof of a dead pixel.
- Repeat in the other orientation if the symptom seems orientation-dependent. Exit normally, rotate the device, and run the sequence again. Use a visible landmark such as a corner or camera cutout to describe the location consistently.
- Exit fullscreen normally and use manufacturer diagnostics. A mismatch that persists should be reported as a visual symptom, not diagnosed as hardware failure. Run the phone or tablet maker's diagnostic tools and follow its warranty process before deciding on repair or replacement.
Read the fields for useful clues
Each solid field creates a different visual condition. A point that remains dark on white or on a primary field may not be emitting light as expected. A point that remains bright or shows an unexpected color component can be easier to notice against black or another channel combination. Different solid fields can therefore expose different mismatches, which is why checking every field is more useful than judging the screen from one color.
Look for the same physical location and the same general behavior each time. Do not assume that a dark point on white and a bright point on black have the same cause. The exact hexadecimal value shown in the progress line confirms which CSS stimulus was requested, but it is not a measurement of the light coming from the panel. A mismatch that changes with the field, viewing conditions, or browser rendering may have a different explanation from one that remains visibly abnormal.
Continue when mobile fullscreen is denied
Fullscreen is only a browser request made by the Start button. A browser can deny it because of permissions, page embedding, organizational policy, platform limitations, or user settings. When that happens, the page reports the failure, and the in-page panel continues cycling through all eight patterns. Clicking, Space, and arrow navigation remain available in that presentation.
The browser retains its normal Escape behavior. The tool does not force kiosk mode, hide operating-system controls, disable sleep, alter brightness, change display settings, or prevent you from leaving fullscreen. If the larger view is unavailable, inspect the visible area, move through every field, and repeat the screen in both orientations while recording which regions you could examine.
Separate a pixel symptom from other causes
A visible mismatch is not automatically a dead pixel. Several conditions can produce a similar-looking result:
- Dust, reflections, screen protectors, and pressure marks can make points appear to be inside the panel.
- Image retention can resemble a fixed defect, while local dimming, image enhancement, HDR, and operating-system color profiles can change the overall appearance.
- Browser zoom, scaling, and GPU output can create content-generation or rendering artifacts.
- Viewing angle, subpixel layout, panel gamut, and hardware calibration can influence how a color field appears.
- Stuck subpixels and hardware faults can also create visible mismatches.
A screenshot can help separate content-generation problems from physical panel problems only when interpreted carefully. A physical defect generally does not become part of a screenshot, while a rendering defect might. That makes a screenshot a clue rather than proof: an absent spot in the image does not certify the panel, and a captured spot does not by itself identify its physical cause.
Record the result for manufacturer support
Before contacting the device maker, repeat the complete sequence and write down the phone or tablet model, screen orientation, color fields on which the spot appears, its approximate location, and whether it remains stationary. Describe what you saw rather than claiming that the test proved a dead pixel. A clear observation such as “one dark point remains near the lower-right corner on white, red, green, and blue” is more useful than “the screen has bad pixels.”
You can keep notes or your own screenshots on your device if you want, but the color test itself uploads neither. Give your observations to the manufacturer, run any built-in display diagnostics the device provides, and let the maker's diagnostic results and warranty policy determine the next step. Avoid third-party repair utilities that ask for unrelated permissions or promise to repair pixels automatically.
Keep the check safe and private
Treat this as a static visual aid. Do not press, tap, heat, or repeatedly flash the panel, and do not install untrusted software or follow a destructive pixel-fixing claim because of a visible spot. The test uses static fields rather than rapid strobe animation. If the display shows spreading damage, electrical symptoms, impact damage, or any safety concern, stop using the device and follow qualified manufacturer guidance.
No screenshot, display identifier, color profile, observation, or navigation history is uploaded. The current pattern index exists only in the browser tab and resets when the page reloads. For the clearest result, clean the outer surface, complete every field without changing browser or device settings, and base any repair request on manufacturer diagnostics rather than a visual mismatch alone.