Editorial standards

Last updated October 28, 2026, for release 2.21.0.

This page says how the tests on this site are built and checked, where the facts in our articles come from, how expert review works, and what happens when we get something wrong. If anything here stops being true, this page changes and the changelog says when.

How the tests are built

Every test runs in your browser, on your device, and nothing you measure leaves it unless you choose to share it. What the site can record, and when, is set out field by field in the privacy policy.

• A test shows you the thing, then tells you what to look for. A dead pixel test fills the screen with one color; a gradient test draws a ramp at device pixels. The page explains which fault each one reveals and which faults are normal for the technology.
• Measured, detected and estimated are labeled apart. A browser knows some things about your screen exactly, guesses others, and cannot see some at all. Refresh rate is measured from frame timing; color gamut and HDR are what the browser reports; physical size is an estimate. When a browser limits what we can measure, the tool says so instead of showing a confident wrong number. The touch sampling readout, for example, warns when the browser hands over only one sample per frame.
• The benchmark's method is published in full. How the score works covers the frame-time windows, the pass criterion, the scoring math and what flags a run. Any change to a scene's workload gets a new benchmark version, and scores from different versions are never compared.
• Public numbers need enough data. A hardware group appears on the benchmarks page only once it has at least 30 anonymous runs. Smaller groups are shown as early estimates, marked as such, or not at all.

How the tests are checked

Every change to the site runs through automated checks: unit tests for the scoring and measurement code, which must pass before anything deploys, and browser tests that open the tool pages at desktop and phone sizes and operate the tools. Every release is listed, dated, in the changelog, including fixes to measurements we got wrong. A browser test is not a lab instrument, and our pages say where the limits are; What a browser benchmark can and can't measure is the long version.

How articles are sourced

• Primary sources first. Facts come from peer-reviewed papers, published standards (IEC, ITU, IEEE, CIE, W3C) and official guidance from professional bodies. Review sites and manufacturer pages are used only for what they are good for, such as measurement methods, and are named as such.
• Every source is listed and checked. Each article ends with its sources. Before an article is published, every link is opened and checked against the claim it supports: the right paper, the right year, the number as the paper states it.
• Evidence strength is stated, not implied. A single small study, a consensus review and a standard are different kinds of evidence, and the article says which one it is leaning on. Where the research does not support a popular claim, we say that too.
• Health topics are not medical advice. Articles on eye strain, flicker, blue light and sleep explain what the research says. They do not diagnose anything. Persistent symptoms are a reason to see an eye-care professional or a doctor.
• Dates are real. Each article shows when it was first published and when it was last reviewed against its sources.
• Tools. We use AI tools to help with research and drafting. A person checks every page against its sources before it is published, and named experts review pages before their names appear.

How expert review works

Some pages are reviewed by an outside expert in the subject: display and color scientists or professional calibrators for the display pages, optometrists and vision scientists for the eye-comfort pages, and sleep and circadian-light researchers for pages about light at night.

• What a reviewer checks. That each claim matches its source, that the strength of the evidence is described fairly, that nothing important is missing (a caveat, a safety note, a group of people the advice does not suit), and, for test pages, that the method measures what the page says it measures. Reviewers send corrections; we make them or explain why not, and the reviewer approves the final text.
• Named only after they agree. A reviewer's name appears on a page only after they have reviewed that page and agreed in writing to be named on it. The byline shows their name, credentials, affiliation, a link to a public profile, and the date of the review. A page without a "Reviewed by" line has not had expert review yet.
• Changes after review. If we change a reviewed page in a way that affects what it claims, we ask the reviewer to look again. Until they have, the byline comes off. Typo fixes and new links do not count.
• Paid for their time, not for a verdict. Reviewers are paid a fixed fee for the time a review takes. The fee is the same whatever they conclude, and they are free to decline to be named.
• No say on ads or products. Reviewers have no say in advertising on the site and do not endorse any product. A review is about whether the page is accurate, not an endorsement of the site.

Advertising

The site is free and is paid for by ads served by Google AdSense. Advertisers do not see articles before they are published and have no say in what they contain, and no test result, ranking or article is paid for.

Corrections

If something we published is wrong, tell us. We fix it in the article itself and update the last-reviewed date, and material corrections get a line in the changelog. When a correction changes what a reviewed page claims, the reviewer sees it before the byline goes back up.

Contact

Corrections, questions about a source, and offers to review: admin@screentest.pro. A link to the page and the sentence in question is the fastest way to get a fix. More about the site is on the about page.