A visual regression is a change to the UI that nobody intended. A refactor to a shared button component nudges the padding on twelve pages. A new global style overrides a heading. A dependency bump changes how a font renders. The code works, the tests pass, the PR merges — and the interface quietly gets worse.
Why they slip through
Traditional safety nets aren't built to catch visual changes. Unit and integration tests assert behavior, not appearance. Code review shows a diff of the source, not a diff of the result — a reviewer approving a three-line CSS change has no way to see that it shifted the layout on a page they weren't looking at. And manual QA can't re-check every screen on every release.
Two kinds of visual testing
There are two distinct questions worth answering, and they need different tools:
- Did the UI change from last time? — snapshot-based visual regression testing compares the current render to a previously approved baseline. Great for catching unintended change.
- Does the UI match the design? — Figma-to-code comparison measures the render against the Figma source of truth. Great for catching implementation drift, even on a brand-new page that has no baseline yet.
Most teams only do the first — or neither. Combining them means you catch both "this used to look right and now doesn't" and "this never matched the design in the first place."
Add the check where work happens
The goal is to surface visual differences at review time, not from a bug report. When a page is ready, capture it — from production, staging, or a local lab environment — and compare it. Attach the resulting diff to the pull request so the reviewer sees exactly what moved. Because each difference comes with the precise values involved, the fix is unambiguous, and you can hand it straight to a developer or an AI coding agent.
Keep the baseline honest
Snapshot testing only works if baselines are maintained — an ignored "everything is different" report trains the team to rubber-stamp changes. Keep diffs small and reviewable, update baselines deliberately, and anchor to the design whenever there's doubt about which version is correct.
The takeaway
Visual regressions are invisible to the tools most teams rely on. Add a dedicated visual check to your workflow, anchor it to the design with a design QA tool, and you turn "someone will notice eventually" into "we caught it before merge."