Skip to main content

Visual Regression Testing With Screenshot Captures

Dev teams use Webshot to catch the kind of bugs unit tests miss — layout breaks, font fallbacks, missing icons, broken responsive states. Capture staging, capture production, diff the pair. Drop the diff in a PR comment as proof your change is safe (or proof the new bug just appeared).

🖥️ Desktop full-page (PNG, sharp diffs) 📱 Mobile full-page ⚙️ Use the free API instead

All buttons open the capture form pre-configured. You can change format and viewport once the page loads.

Why Webshot for this

Pixel-accurate captures

PNG mode preserves crisp text and edges — ideal for pixel-diffing tools (`pixelmatch`, ImageMagick `compare`) where JPG compression noise would create false positives.

Same viewport every time

Webshot captures at the exact same viewport, scroll position, and font-loading wait time on every run — diff results are reliable.

API-friendly

Wire up the free Webshot API to your CI: capture pre-deploy and post-deploy, diff with `pixelmatch`, fail the build if pixels-changed > threshold.

No headless-Chrome boilerplate

Skip puppeteer setup, font installation, sandbox flags. Webshot has all that running on our infra. Your CI just does an HTTP call.

How to capture visual regression testing

  1. Pick the page(s) you want to monitor — homepage, key landing pages, checkout flow, anywhere a regression would hurt.
  2. Capture each at PNG + desktop_full + mobile_full to baseline your current production look.
  3. After your next deploy, capture the same URLs again. Diff old vs new with `pixelmatch` or ImageMagick — anything > 1% pixel-changed deserves human review.
  4. Wire it into CI: a pre-deploy hook captures staging, a post-deploy hook captures production, and the build fails if the diff exceeds your threshold.

Frequently asked questions

Headless Chrome in CI means installing Chromium, fonts, the sandbox kernel-flags, plus keeping it all updated. With Webshot you skip the install entirely — your CI does an HTTP call to our API and gets a PNG back. We handle Chrome updates, font caching, and SSRF protection.

Yes when you use PNG + same viewport + same wait strategy. Webshot pins viewport size and waits for fonts.ready + network-idle + any animations declared via the `prefers-reduced-motion` query. Random animations (lottie loops, Date.now() backgrounds) will diff differently every run; freeze those in your test environment.

Not in one call — you capture each URL separately, then diff them with a separate library. We're keeping the API focused on capture; diffing is a 30-line script. See `/developers` for example code.

Yes. Webshot waits for network-idle (no requests for 500ms) and fonts.ready before capturing, so React, Vue, Svelte, and Next.js apps all render fully before screenshot. For sites that never reach network-idle (long polling, websockets), you can pass a `maxWait` parameter via the API.

The free public form is 5/15-min per IP — too low for CI. The free API tier is more generous; see `/developers`. For high-volume regression testing (50+ captures per build), the commercial API plan removes per-IP caps.

Webshot itself just captures — you provide the diffing layer. Two-line solution: `npx pixelmatch baseline.png new.png diff.png`. Or use a managed visual-diff service (Percy, Chromatic, BackstopJS) and feed Webshot's PNGs into them.

Ready to capture?

Free, no signup, no watermark. Just paste a URL.

📸 Open the capture form

Other use cases: Google Maps Screenshots · WordPress Screenshots · Landing Page QA · Legal Evidence Screenshots · Social Media Screenshots · See all →

Share: 𝕏 Twitter Facebook LinkedIn