The quickest way to get a misleading visual diff is to compare captures made under different conditions. Two screenshots of unchanged code can disagree because one browser is wider, one font arrived late, or a carousel advanced between captures. Treat the capture setup as part of the test.
1. Prepare the page state
Decide what the comparison is meant to answer. “Did the checkout summary change after the CSS release?” is testable. “Is the new site better?” needs broader design and usability review.
Before each capture, record or match these conditions:
- Route and data: use the same URL, account state, sample record, filters, and query parameters.
- Viewport and zoom: keep the same CSS viewport, browser zoom, and device pixel ratio when possible.
- Scroll position: start at the same vertical and horizontal offset. Sticky elements react to scroll.
- Transient UI: close consent banners, tooltips, chat widgets, menus, and browser translation prompts in both captures.
- Timing: wait for web fonts, images, and layout shifts to settle. Pause animations if the product allows it.
2. Capture a fair before-and-after pair
Capture directly from the browser instead of photographing the screen. Screen photos add perspective, glare, scaling, and camera processing. Browser screenshots preserve a flat pixel grid that a comparison tool can evaluate.
- Open the baseline version and reproduce the chosen page state.
- Wait for the page to settle, then capture the “before” image.
- Open the changed version at the same viewport and state.
- Capture the “after” image using the same method and file format.
- Name the files with context, for example checkout-desktop-before.png and checkout-desktop-after.png.
Full-page screenshots are convenient, but they are more exposed to lazy loading, sticky navigation, and content that changes with time. For a focused review, a stable section-level capture often produces better evidence.
3. Run the comparison
Open SiteReceipt and select the before and after images. Image decoding and comparison happen in your browser. The screenshots are not sent to SiteReceipt for processing.
Begin with the default sensitivity. Inspect the result before moving the control. If every letter edge is highlighted, first check the viewport, font rendering, and image scaling. Lowering sensitivity can hide noise, but it can also hide a small real change such as a one-pixel shift or a muted text color.
A disciplined review uses three views:
- Before: confirm that the baseline itself is the version you intended to test.
- After: inspect the current design without diff colors covering it.
- Difference view: locate changed regions, then return to the source views to understand them.
4. Interpret the result
A highlighted area means SiteReceipt found enough sampled color differences in that region at the selected sensitivity. It does not say whether the change is correct. Group the result into three buckets:
| Bucket | Typical signal | Next action |
|---|---|---|
| Expected | Changed button color, approved copy, new component | Record the reason and mark it accepted |
| Unexpected | Missing icon, clipped label, shifted price, altered spacing | Reproduce in the product and open a focused issue |
| Environmental | Different line wraps, font-edge halos, rotating media | Normalize the capture and compare again |
Review large changes first because they can move everything below them. A new two-line heading may explain dozens of lower-page differences. Do not count each displaced section as an independent defect.
Worked example: a checkout summary
An agency needs to verify a checkout card after a design-token update. The first comparison highlights most of the card. The heading wraps in the after image, the order total is lower on the page, and every row below it appears displaced.
The captures reveal that the after browser was 24 CSS pixels narrower. The reviewer retakes the after image at the correct width. The second comparison isolates two regions: the approved navy button color and an unexpected one-pixel gap below the tax row. The team accepts the button and fixes the spacing before client review.
The useful outcome is not “pixels changed.” It is a short explanation of which visible changes were intentional, which required correction, and which capture condition caused the initial noise.
What screenshot comparison cannot prove
- It checks one rendered state, not every viewport or user journey.
- It does not inspect the DOM, CSS rules, network requests, or source code that produced the pixels.
- It cannot determine whether an approved-looking result is accessible to keyboard or assistive-technology users.
- It cannot reliably judge moving video, live data, random content, or third-party widgets without additional controls.
- It does not assign intent. A human still decides whether a visible difference is expected.
For the mechanics behind the result, read the SiteReceipt comparison methodology.
Frequently asked questions
Do the two screenshots need the same dimensions?
Matching dimensions gives the cleanest result. If dimensions differ, first determine whether the viewport or crop changed. A tool may fit both images into a shared comparison area, but that does not make two different layouts equivalent.
Should I compare PNG or JPEG screenshots?
PNG is usually easier to review because it avoids JPEG compression blocks around text and edges. If the source is already JPEG, use the same quality and capture process for both files.
What should I do when all text is highlighted?
Check browser zoom, operating-system scaling, device pixel ratio, web font loading, and image resizing. Thin halos around every glyph usually point to rendering conditions rather than edited copy.
Can I use a screenshot diff as final client approval?
It can support approval if the report identifies the page state and decision. Keep a separate written record of who approved what and when. The client approval guideexplains a practical workflow.