Mobile screenshot testing across responsive breakpoints

Pick the breakpoints that actually matter

Don't test every viewport in your CSS. Test the viewports your actual visitors use. Pull a 30-day report from your analytics; group by device class and viewport width band; pick the top three or four. For most consumer- facing sites this looks roughly like:

• Desktop at 1440 × 900 - covers the median MacBook + external monitor user.
• Laptop at 1280 × 800 - covers older MacBooks and most Windows laptops.
• Tablet portrait at 768 × 1024 - the iPad-class viewport where most teams break their layout because they design for it third.
• Mobile portrait at roughly 390 × 844 (iPhone-class). The single most important viewport on the list.
• Mobile landscape at around 844 × 390 - rare but where weird grid bugs hide.

That's five captures per page. If you have ten important pages, that's fifty captures per release. Manually that's a person-hour. Automated it's a two-second command.

The free workflow (one-time capture)

For a one-off design review or bug report, the workflow is:

1. Open the screenshot tool, paste the URL, click Capture all viewports.
2. You get a side-by-side comparison of desktop, tablet, and mobile. Eyeball it for the regression you're looking for.
3. If you need the mobile-landscape view or a custom breakpoint, switch viewports and capture again - or enter custom width and height in advanced options.
4. Download PNGs and drop them into the bug report or design comment.

The tool runs Chromium server-side, waits for network idle, and auto-scrolls to surface lazy-loaded content - so JavaScript-rendered apps and pages with IntersectionObserver images all work without configuration.

The scaled workflow (every release)

For continuous mobile regression catching, capturing manually after each release stops being viable around the third sprint. The pattern that scales: pre-configured monitors that capture the same set of breakpoints on a schedule, diff each capture against the prior one, and alert only when something visibly changed.

Inside OnChange, this looks like:

• One monitor per (page, breakpoint) pair. A pricing page at desktop and a pricing page at mobile are two monitors so the diffs stay clean.
• Visual diff mode enabled. Pixel-level comparison flags real layout shifts and ignores text content changes you already track on the desktop monitor.
• Sub-minute intervals for revenue-critical pages, hourly for everything else.
• Slack alerts routed to the channel of the team that owns the page. Visual diff thumbnail attaches inline so triage is instant.

The cost of running this on a Free plan is zero (five monitors); Pro gets you fifty.

Common mobile regressions this catches

• Hero CTAs that wrap to two lines on mobile after a copy change.
• Pricing cards that overlap when the design team adds a new feature row.
• Sticky headers that swallow the first 60px of content on iOS Safari.
• Below-the-fold images that fail to lazy-load because someone replaced loading="lazy" with eager.
• Navigation menus that don't collapse to a hamburger at the new breakpoint after a refactor.
• Buttons that overflow the viewport because someone added a longer label without updating the constraint.

Frequently asked