The short answer
Compare a design frame and browser screenshot after matching their viewport, content, fonts, theme, and state. Review hierarchy and layout relationships before small pixel differences. Use an overlay as evidence of a mismatch, then verify the intended behavior in the running product.
1. Match the conditions before comparing
Choose the frame that represents the implemented screen and set the browser to the same CSS viewport width. Record browser zoom, device pixel ratio when relevant, theme, and data state. Exported screenshot pixels may differ from CSS pixels, so establish the relationship before interpreting an overlay.
Use equivalent content. A short placeholder name in the design and a long customer name in the browser can create different wrapping without a spacing defect. Check that the intended font has loaded and that the two views show the same selected, expanded, or validation state.
2. Check the structure before the decoration
Start with the screen’s purpose, primary action, information order, and alignment. Then compare component choice, text hierarchy, spacing roles, image crop, and surface treatment. A slightly different border is less important than an action appearing beside the wrong decision.
Write down the rule behind each difference. For example, a panel might need to align with the content grid, or the gap between a label and its field might need to use the shared form spacing. This makes the correction reusable instead of turning the screen into a collection of isolated coordinates.
Comparison record
Design: [frame and version]
Build: [URL and version]
Conditions: [viewport, zoom, theme, content, state]
Mismatch: [specific element and observed difference]
Intended rule: [alignment, component, token, or behavior]
Scope: [affected instance or shared implementation]
Verification: [original comparison plus a nearby responsive state]3. Use overlays to locate differences
An overlay can make a shifted edge, changed crop, or inconsistent panel width easier to see. Keep the captures aligned at the same scale, then vary opacity or compare them side by side. If the whole screen drifts at once, revisit the capture conditions before filing dozens of comments.
Pixel differences are not automatically product defects. Font rendering, platform differences, and dynamic content can change screenshot output. Playwright’s visual comparison documentation describes environment-related variation and baseline handling. Keep a human decision about whether a visible difference violates the approved intent.
4. Verify the correction in the live flow
A screenshot shows one state. Open the implementation and check focus, hover, validation, scrolling, and the next screen where relevant. A change that improves a static comparison may still clip longer content or make a control harder to use.
Send a focused correction with its reference frame, current screenshot, and acceptance check. CRRT can attach the visual observation to the relevant element on a supported web surface. Review the resulting implementation at the original width and a narrower width before treating the mismatch as resolved.
- Confirm that the reference is current and approved.
- Separate intentional browser adaptations from unintended drift.
- Reuse the existing component or token when it expresses the rule.
- Record what the screenshot comparison did not test.
Common questions
Should a browser screenshot match a design pixel for pixel?
That depends on the agreed acceptance criteria and environment. Review whether the implementation preserves the intended layout, hierarchy, and behavior; explain any tolerance for rendering differences.
Can a matching screenshot prove the flow works?
No. It cannot establish keyboard behavior, validation, persistence, navigation, or states outside the captured image. Test those in the running product.
Sources & further reading
Written with AI assistance. Tool references checked against the linked documentation on November 2, 2026. Examples are starter templates to adapt and review in your own project.