Step 1
Capture a baseline
Screenshot any URL in its known-good state. Real hosted Chromium renders the full page — lazy content, web fonts and all — and stores it as your reference.
Catch unintended visual changes before your users do. Capture a baseline of any page, re-capture on every deploy, and get a pixel-diff that highlights exactly what moved.
⚠ Visual regression detected
4.1% of pixels changed vs. baseline, above your 1% threshold. Changed regions: hero headline, primary CTA.
Warm dashed boxes mark every changed region · never color alone
Visual regression testing is the practice of comparing how a page looks before and after a change, instead of only asserting that the code still runs. You take a screenshot of a known-good state — the baseline — then re-capture the same page after a deploy and diff the two images pixel by pixel. Anything that moved, broke, or disappeared shows up as a highlighted region.
It matters because the things that silently break layouts rarely fail a unit test. A CSS refactor shifts a button two columns over. A dependency bump changes a font's line-height. A content edit overflows a card. The build is green, the tests pass, and the page is visibly wrong. A pixel-diff catches exactly those cases — the regressions your assertions can't see.
Four steps, one API. Capture a baseline once, then let every deploy check itself against it.
Screenshot any URL in its known-good state. Real hosted Chromium renders the full page — lazy content, web fonts and all — and stores it as your reference.
After a deploy, dependency bump or content edit, re-capture the same page at the same width. Identical requests are cached, so repeat captures cost nothing.
A true pixel comparison runs against an adjustable sensitivity. Minor noise — a rotating testimonial, a timestamp — stays quiet; a real structural change crosses the threshold.
When the diff exceeds your threshold, you get an email alert with the changed regions outlined — warm dashed boxes paired with a ⚠ label, so the result is never read by color alone.
Add one step to your deploy pipeline: capture the page, compare it to the baseline, fail the build if the diff crosses your threshold. It's a plain HTTP request hitting /v1/capture — no headless browser to install, no flaky local Chromium to babysit.
For AI agents, the same comparison is one call: the MCP compare_screenshots tool diffs staging against production in a single step, so an agent can verify its own change visually.
# 1 — capture the page under test
curl "https://screenshotink.com/v1/capture" \
-H "Authorization: Bearer sk_live_…" \
-d url="https://acme.com/pricing" \
-d full_size=true -d format=png{ "changed_pct": 4.1, "passed": false,
"regions": ["hero", "cta"] }CI catches regressions on deploy. But pages also drift between deploys — a CMS edit, an expired asset, a third-party widget that changes itself. Scheduled monitoring runs the same pixel-diff on a timer, daily or hourly, and alerts you when a live page moves without a deploy behind it.
It's the same capture engine and the same diff, whether you trigger it from CI, a cron, or an AI agent. Want to see how it stacks up against dedicated visual testing tools? The comparison page lays out the differences.
EU-hosted · free key includes 100 captures / month · no card
Capturing a baseline screenshot of a page, then re-capturing it after a change and comparing the two pixel-by-pixel to catch unintended visual differences — layout shifts, broken styles, missing content.
A pixel-level diff against the previous capture, with a sensitivity threshold you control to ignore minor anti-aliasing noise. Changed regions are highlighted.
Both. Call the capture API from your pipeline on every deploy, or set up a monitor that re-captures on a schedule and emails you when something crosses your threshold.
Yes — the MCP server exposes a compare_screenshots tool, so an agent can diff staging against production and report what changed, with the diff image returned inline.