Responsive capture begins with CSS pixels
A device label is convenient, but width and height are the reproducible contract. The requested width determines media queries, navigation variants, grid columns, and often which image resource the page loads. Height controls the visible fold and can affect sticky elements or viewport-relative components.
Write the dimensions into the test or monitoring specification. Future reviewers should not need to infer them from the image.
Avoid a device catalog without purpose
More viewports do not automatically create better coverage. Choose a small matrix from actual breakpoints, user analytics, and the routes where layout defects matter. A product may need one compact mobile width, one wider mobile or tablet state, and one desktop state. Another product may need a different set.
Capture representative fixtures before scaling the route list. Confirm fonts, menus, tables, charts, and consent behavior at every chosen width.
Keep baselines independent
Do not compare a mobile image against a desktop baseline or treat their mismatch as a regression. Each viewport is a separate approved state with its own before and after artifacts. Preserve the exact dimensions, format, readiness, cleanup, target version, and capture time.
Full-page mode does not remove the viewport. Width still selects responsive layout; only the output extends vertically. Long captures can also reveal repeated sticky elements or incomplete lazy content, so test them separately from viewport-only images.
Use mobile screenshots for a broader responsive workflow and the visual diff API when each viewport needs controlled before-and-after evidence.
