Screenshot testing vs visual regression testing

These phrases are used as synonyms in most job descriptions and half the tooling documentation, which is usually harmless. It stops being harmless during a tool evaluation, because a team can buy a screenshot mechanism when what they needed was a regression workflow, and discover the gap six weeks in.

The short version

• Screenshot testing is the mechanism: render a page or component and capture an image.
• Visual regression testing is the practice: store baselines, compare every build, triage differences, approve intended changes, and keep the whole thing trustworthy over time.
• Snapshot testing is a third, frequently confused thing: serialise a component's rendered output to text and diff the text. No image, no browser.

Screenshot testing is a component of visual regression testing in the same way that taking a photograph is a component of running a security camera system. The capture is the easy half.

Snapshot testing is not visual testing

This is the confusion with the most practical consequences, because snapshot tests look like they provide visual coverage and do not.

// A snapshot test: this serialises markup, not appearance.
it("renders the pricing card", () => {
  const { container } = render(<PricingCard plan="team" />);
  expect(container.firstChild).toMatchSnapshot();
});

That assertion passes whether the card is laid out perfectly or rendered as a single unstyled column with white text on a white background. It compares a DOM string. It has no browser layout engine, no CSS cascade, and no concept of what overlaps what.

What visual regression testing adds to a screenshot

Take a screenshot and you have a file. To turn that into something that protects a product, you need every item below — and the difficulty of the list is why visual regression testing is a category rather than a function call.

1. 01A baseline — an approved reference image per page, per viewport, per browser, and a decision about where it is stored.
2. 02A comparison — tolerance for antialiasing and rendering noise without discarding real differences. See fixing flaky visual tests.
3. 03Triage — ranking and grouping differences so a reviewer reads the important one first instead of the thousandth pixel.
4. 04An approval path — a way to promote an intended change to the new baseline, with a record of who approved it.
5. 05Coverage management — knowing which routes and states are covered, and noticing when new product surface is not.
6. 06Determinism — fonts, animation, time, and data controlled so the same code produces the same image.

Steps 3 through 6 are where teams that rolled their own stop. The capture script took an afternoon; the review workflow, the approval audit trail, and the coverage ledger never got built, so the suite reported differences nobody could act on.

A comparison table, in words

• What runs it — snapshot testing: a test runner, no browser. Screenshot testing: a real browser. Visual regression testing: a real browser plus a comparison and review service.
• What it catches — snapshot: markup changes. Screenshot: whatever you point it at, once. Visual regression: unintended appearance change, over time, across the covered surface.
• What it misses — snapshot: everything visual. Screenshot: everything you did not capture. Visual regression: states, routes, and viewports outside its coverage.
• Main failure mode — snapshot: mass-approving churn until the test is meaningless. Screenshot: no baseline, so no signal. Visual regression: flake and reviewer fatigue.
• Cost — snapshot: near zero. Screenshot: low. Visual regression: real, and mostly in maintenance rather than licence.

Which do you actually need?

Most products with a customer-facing interface need all three, scoped differently.

• Snapshot tests for pure logic components and rendered output where markup stability genuinely matters. Keep them few; they churn.
• Screenshot captures as debugging evidence attached to failing end-to-end runs — enormously useful, and not a regression suite.
• Visual regression testing for the routes where a broken layout costs you money: sign-up, pricing, checkout, and the screens people spend their day in.

If you are choosing a tool for that third category, the questions that predict success are in how to evaluate visual regression testing tools — and the first one is whether coverage is something you author or something the tool discovers.