A screenshot baseline is a reference image used to compare later observations. After a redesign, it needs to change. The difficult part is deciding which differences are intended, which reveal a regression, and which come from a different capture environment.
Treat baseline approval as a review decision with evidence. Replacing every old screenshot because the release looks broadly correct can preserve defects as the new reference and remove the easiest way to explain what changed.
Preserve the last reviewed reference
Keep the previous approved capture available while reviewing the redesign. Identify its page, viewport, capture conditions, and release. Save the candidate image separately so that approval does not erase the comparison that supported the decision.
The baseline should represent an understood state. A screenshot that happened to be captured most recently is not automatically suitable. Check for loading placeholders, consent overlays, missing fonts, and error screens before using it as a reference.
If the old baseline is already unreliable, record that problem. You may need a fresh controlled reference rather than an approval that pretends the historical comparison was valid. The dynamic content guide helps diagnose common capture inconsistencies.
Make capture conditions comparable
Record the viewport, browser environment, page state, and relevant data or account context. For controlled tests, keep those conditions consistent between the reference and candidate. A changed environment should be a visible part of the review.
Playwright's visual comparison documentation notes that rendering can vary with operating system, browser, fonts, and other conditions. A difference caused by those factors is still visible evidence, but it may not indicate a change in the website's intended design.
Do not use an extremely permissive threshold to hide an unexplained environment change. First establish whether the new capture is comparable. If you intentionally change the test environment, review the resulting reference update as its own decision.
Define the expected redesign boundary
Write down what the release intends to change. “New homepage” is less useful than a short list covering the header, hero layout, typography, and navigation behavior. Include what should remain functionally equivalent, such as the ability to reach pricing or complete signup.
Use the boundary to organize the review, not to excuse everything inside it. A redesigned hero can legitimately move the main heading while still introducing an unintended text overlap on a narrow screen.
For a fictional product site, the review might look like this:
| Area | Intended difference | Separate check |
|---|---|---|
| Header | New spacing and navigation treatment | Links remain reachable at narrow widths |
| Hero | Updated layout and shorter headline | Primary action is visible and text does not clip |
| Pricing | Typography follows the new design system | Amounts and billing periods remain correct |
| Footer | Reorganized columns | Legal and account links still work |
This turns a large image diff into a set of decisions reviewers can explain.
Review representative conditions, not one attractive screenshot
Choose viewports and page states that reflect the design's actual risks. A layout that looks balanced on a wide screen may wrap poorly on a phone. Long text, empty results, validation errors, and expanded controls can expose defects hidden by the default state.
Where components are shared, inspect their representative contexts. A new button style may work on a light card and become unreadable on a dark section. A global spacing change may affect forms differently from editorial pages.
Keep the review scope explicit. A screenshot comparison can support a visual decision, but it cannot establish keyboard behavior or all programmatic accessibility properties. Use the accessibility retest guide for changes that affect those concerns.
Approve with a small decision record
A useful baseline approval needs the reference, candidate, affected release, reviewer, date, and reason. List any exceptions or unresolved defects. Link the decision to the issue or release record that explains the intended change.
For example: “Approved the new article header layout for desktop and mobile after verifying title wrapping and navigation. Pricing table overflow remains open under UI-42; its candidate baseline is not approved.” This is more informative than “updated screenshots.”
Do not mix known defects into an approval without stating them. If the workflow requires a temporary reference for ongoing work, label its provisional status and keep the corrective action visible. Otherwise, the next reviewer may interpret acceptance as evidence that the defect was considered correct.
Recheck the released page and keep the evidence connected
The approved candidate may come from a preview environment with different fonts, content, or configuration. After release, compare the actual deployed state under the intended monitoring conditions. Investigate material differences before treating the redesign review as closed.
Preserve the relationship between saved images and their supporting page evidence. HTML, CSS, and screenshots answer different questions; combining them can help distinguish a content edit from a presentation change. OnChange's snapshot comparison workflow provides a place to inspect preserved page states when investigating those differences.
The next baseline should be an approved reference with a clear origin. Keeping the old reference, the candidate, and the decision together makes the following release easier to review and prevents visual monitoring from becoming a series of unexplained resets.