How to Test a Monitor Without Chasing False Alarms
Separate a screen symptom from its source, understand what a built-in monitor diagnostic changes, and turn a repeatable comparison into useful support evidence.
By FreeScreenTest · Published October 2, 2025 · Updated
Before you enter fullscreen
Clean the screen according to its manual while it is off. When you turn it back on, select the input and picture mode you actually plan to use. Write down the brightness setting, connection, source device, room light, and operating-system scaling. That small note prevents a later photo from becoming a mystery.
Use the display's native or recommended resolution unless you are investigating scaling. Windows normally marks the suitable choice as Recommended in Display settings. Close overlays, notification panels, night-light filters, and anything else that changes the image temporarily.
Use two room conditions on purpose
Normal room light tells you whether a problem matters during real use. A dim room can make black-screen edge light easier to see. Do not compare two auto-exposed camera photos as if their brightness were measured.
First: check things that stay in one place
Open the dead pixel test and cycle through black, white, red, green, and blue. A suspect point is worth recording when it stays at the same physical screen location while the background changes. Move a window beneath it and repeat on another input when practical. If the point is visible with the display off, check for a surface mark; follow the manual before cleaning again.
Fullscreen must follow a user action and the browser can refuse it. If that happens, keep using the pattern in the available window or review the browser's fullscreen permission; this behavior is part of the Fullscreen API, not evidence of a monitor fault.
Does the mark travel with the content?
A location is more useful than a label like “broken pixel.” On the affected screen, move a window containing the suspicious image and watch the mark relative to the screen's edge. These illustrations show the two observations to distinguish.
Teaching illustration: both dots below are drawn by this page. This demonstration is not a hardware photo or an automatic defect detector.
A · The dot follows the window
B · The dot keeps its position
Compare position against the screen edge, not against the changing picture.
A fixed position does not distinguish surface dirt from a panel or signal-path problem by itself. A changing position does not identify which app, driver, or source is responsible. Record the comparison before naming a cause.
Turn that comparison into a usable record
Write: “The point was about __% from the left and __% from the top. It [moved / stayed] when the window moved. It was visible on __ backgrounds. On a second source, __.” Leave an unperformed comparison as “not checked.”
Run the solid-color check, save the observation, then select it in the report builder. Add the actual setup and original photos there. A support reader can then repeat the conditions you used.
Next: look across the whole panel
Return to your normal chair position and brightness. Use the uniformity test to find patches or tint, then the gradient test for visible steps and the text test for fringing or soft strokes. Describe the location and the content that reveals it; “looks bad” is hard to reproduce.
Now change one variable. Try the original picture mode, restore the display's native resolution, or use a known-good input path, then return to the first setup. Keep OS scaling and browser zoom fixed unless you are testing those settings. A change that follows a mode or source may still matter, but it is not the same evidence as a patch that remains fixed on the panel. Browser patterns cannot assign a numerical uniformity, color-error, or contrast value; that requires measurement equipment.
Then: compare motion without hiding the tab
Confirm the selected resolution and refresh rate in the operating system. Keep the refresh-rate check in front, because browsers commonly pause animation callbacks in hidden tabs. Then use the motion pattern to compare overdrive or picture modes at the speeds you actually use.
Look for a direction: fewer trails, new bright halos, or a cadence that changes with the selected mode. Browser animation timing is not a sensor reading of panel scan timing or pixel transitions. MDN's requestAnimationFrame reference explains why tab visibility and browser scheduling affect it.
Does the symptom remain without the computer's picture?
Opening another browser still uses the same computer, graphics path and cable. A monitor-generated diagnostic image is a different comparison: it supplies the picture inside the display. Use it when a fixed mark or line remains after the surface and content checks; do not substitute a black “no signal” screen for the documented diagnostic.
A real manual example: Dell U2720Q / U2720QM
The January 2020 Rev. A00 manual, printed page 53 requires the video cable to be unplugged and the monitor to be in self-test mode. It describes holding Button 4 for four seconds, selecting the self-inspection icon, and inspecting gray followed by colors and text using Button 1. The button diagram on that page identifies the controls. This is a model-specific example, not a universal key sequence.
Source checked September 22, 2026. Find the matching manual for your own model before disconnecting or pressing controls. If no internal diagnostic exists, record that limit and compare a known-good source when practical.
Swipe across the table to read all three columns.
| Observation | Useful inference | Next action and remaining limit |
|---|---|---|
| The same fixed mark appears in the monitor's internal pattern | The computer's drawn image is not needed to reproduce this observation. | Record the diagnostic screen, position and photos for the display maker. Surface dirt still needs ruling out; this does not name the failed component or decide warranty coverage. |
| Internal patterns look normal, but the connected picture has a line | The symptom was not reproduced under the internal test conditions. | Reconnect the original setup. Compare one known-good cable, input or source at a time. Do not call the display fault-free: an intermittent issue or an input-specific problem may be outside this check. |
| A second source changes the appearance | Something in the changed path or its settings matters. | Write down which cable, port, source and mode changed. If several changed together, the result does not isolate one faulty part. Return to the first setup and narrow the comparison. |
| The issue is absent from a screenshot opened elsewhere | That captured image does not contain the visible symptom. | Compare a camera photo and the independent diagnostic. Screenshot timing, overlays and capture behavior limit this comparison; absence alone is not proof of a panel defect. |
Save only evidence you can explain
Repeat the finding after restoring the recorded setup. For a physical mark, take one close camera photo and one wider photo showing its screen location. A screenshot records the rendered image, so it usually cannot capture a physical dead pixel, backlight patch, reflection, or viewing-angle change.
Use each test's save control to keep an observation in Test History. Add settings, notes, and photos in the defect report builder and export the report before leaving that page. Saved history persists in this browser; an unfinished report does not.
From “bad screen” to a repeatable observation
Constructed example of record-writing. These are invented observations, not a product review or a test of your screen.
- Starting setup and observation
- “Desk display, HDMI from laptop, SDR, brightness 35%, ordinary room light. One bright point near 80% from the left and 20% from the top on black.”
- One comparison
- “Moved the black window while watching the point against the bezel. It stayed at the same screen position. Returning the window to its starting place did not change that.”
- What this rules out—and what it does not
- The observation is inconsistent with a dot attached to that window. It does not distinguish a surface speck, panel fault, or another fixed overlay. “Surface inspection, another source and built-in diagnostics: not checked.”
- Next action and a narrow request
- Check the surface and the independent source below before naming a fault. If the point remains, attach an overview and close photo and ask support: “Which diagnostic and pixel policy apply to this model and purchase?”
Keep observations separate from explanations. In the report's first step, enter your own setup, change, repeat result and unknowns. Do not copy this example as a finding.
Which question is still unanswered?
Choose the comparison that addresses your remaining symptom. You do not need to complete every tool to make a useful record.
- A point stays in one physical location
- After the surface and content checks above, use the pixel evidence guide to compare camera and screenshot evidence, then find the policy for your exact purchase.
- A pale corner or edge is visible on dark content
- Follow the four dark-patch comparisons. Separate room light, viewing position, picture settings, and camera exposure before deciding what remains distracting in normal use.
- A gradient shows steps
- Compare the downloadable reference with known gray values in two viewers. This checks whether encoded steps or the viewing path account for the appearance; counting bands cannot identify panel bit depth.
- A previous image leaves an outline
- Use the retention recheck to record whether the shape changes after ordinary content. Follow the model's documented care process; persistence in one inspection does not establish permanence.
- Letters look soft or have colored edges
- Start with the text symptom table. One-app blur, scaling changes, and a problem across all apps call for different comparisons.
- Motion trails, tearing, or uneven cadence remain
- Use gaming settings by symptom to separate refresh selection, frame delivery, synchronization, and overdrive. Keep the browser pattern and the actual game comparison distinct.
Stop when you have a usable setup or a repeatable observation to report. Record “no issue observed under these settings” only for checks you completed. Leave unperformed comparisons as “not checked”; a support reader needs those limits too.