Guide · visual checks

What a failed visual check proves and does not prove

First published November 10, 2026 · Facts checked November 10, 2026

Short answer

A failed visual check shows that a recorded image or visible assertion did not match on that run. It does not name the cause, prove a business action failed, or show that every other page or device is broken.

On this page

Context and limits

A failed visual check means the comparison you recorded did not match on that run. The mismatch is the fact. The reason for it, and what it means for the rest of the site, are separate questions. This page is about reading one failure. It is not a buyer’s guide to visual-regression products.

Have a site ready to check? Test my site free. Add your URL and review a test plan before starting a run. See a sample report first.

The fact a failure records

Read the failure as a comparison, not as a diagnosis. A snapshot check compares a new image with a stored image and reports a difference past a threshold. A layout assertion reports that a measured thing, such as overflow or a missing heading, did not meet the rule you set. Either way, the report should name the page, the viewport, and what was compared.

Keep those three with the failure. A red result with no page, no width and no image is a label, not a check someone else can repeat. How to file a QA result is the record to use.

Playwright’s snapshot docs describe image comparisons against a stored baseline, and they warn that rendering can change with the operating system, browser, settings and hardware. A difference can be that environment gap. The docs are the source for how that tool defines the comparison. This page does not restate them as a Sybqa measurement.

What you may conclude

On this run, at the recorded URL and viewport, the comparison did not match.
The evidence you actually hold is the pair of images, the diff, or the assertion text. If one of those is missing, say so.
The same mismatch appearing at two widths is still one observation until you show they have different causes.
An intentional design change can fail a baseline that nobody updated. That is a process fact, not proof of a defect.

Sybqa does not keep an approved screenshot of every page and diff each build against it. A Sybqa finding is evidence from the run you started: screenshots and steps when they were captured, plus the result of the checks in the plan. Read it as that run, not as a baseline product. The visual regression versus website QA guide separates those two jobs.

What you may not conclude

The failure does not name the cause. CSS, content, a font, a cookie banner, an animation or a different machine can all move pixels.
It does not prove a click, a payment, a saved record or an email. A picture of a button is not a picture of the action completing.
It does not prove the rest of the site failed. Pages and widths that were not compared stay unknown.
It does not prove the change is a regression. If the new look is what you wanted, the baseline is stale. Update the baseline on purpose and say who approved it.
A blocked or not-run visual check is not a failure and not a pass. Blocked is not passed.

If the mismatch is something a person would also call a bug, confirm it by repeating the steps. The false-positive worksheet is for a finding that might not hold up. A pixel diff you have not looked at is still a lead.

Decide the next step from the evidence you have

Three honest next steps: accept an intentional change and replace the baseline, file the mismatch as a defect with the images attached, or mark the check blocked because the capture or the environment is not comparable. Picking one is the decision. Leaving the row red without a decision is not.

Do not publish a pass rate from one failed check. One failure is one row. It is not a percentage of the product.

Common questions

What does a failed visual check prove?

That the recorded comparison did not match on that run, at the URL and viewport you wrote down, using the images or assertion you kept.

Does a failed screenshot mean the feature is broken?

Not by itself. It means the image differs from what you compared it with. Repeat the steps and separate an intentional change from a defect.

Should an intentional redesign fail the check?

It will, until someone approves a new baseline. The failure then records a stale baseline, which is a real process event, not a user-facing defect.

Sources

Try Sybqa on your site

Explore bugs, UI consistency and user journeys from a reviewed plan. Inspect browser evidence and visual review leads in the report. The free plan gives 10 runs a month without AI review after you sign up. See pricing.

Add your site link here and it will be waiting in the console after you create an account. Then describe one journey to check and review the test plan before any run starts.