Screenshot Comparison Tool

What is a screenshot comparison tool?

A screenshot comparison tool takes two images of a web page and tells you what is different between them. Instead of squinting at two browser tabs, you get an exact answer: which pixels changed, how many of them, and where on the page they sit.

This one goes a step further than a plain image differ. You give it two URLs rather than two files, and it renders both pages live in a real browser before comparing them, so you never have to take, save, and upload the screenshots yourself.

The typical use is catching an unintended visual change: a CSS refactor that quietly moved a button, a font swap that reflowed a heading, a third party script that shifted the layout. Those are the changes that pass every unit test and still ship a broken page.

How to compare two website screenshots

Paste both URLs above and hit Compare. The result gives you three ways to look at the same diff, because different kinds of change are easier to spot in different views:

• Side by side: the two renders next to each other, best for spotting a change you can describe in words.
• Difference: the baseline dimmed with every changed pixel highlighted, best for finding small shifts you would otherwise miss.
• Slider: one image wiped over the other, best for judging whether a change is an improvement or a regression.

What is visual regression testing?

Visual regression testing is the practice of capturing a screenshot of a page in a known good state, then comparing every later build against that baseline. If the diff is bigger than your threshold, the build has changed something visually and a human should look at it.

It closes a gap that other tests leave open. Unit tests confirm a component returns the right markup, end to end tests confirm the flow completes, but neither notices that a stylesheet change made your pricing table overlap its own footer. Only a picture catches that.

This tool is the manual version of that loop: one baseline, one candidate, one diff. If you want to automate it in CI, we wrote a walkthrough of the full pipeline in visual regression testing with a screenshot API.

How pixel diffing works, and what threshold to use

A pixel diff walks both images one pixel at a time and measures how far apart the two colours are. Comparing raw RGB values is too naive, because the human eye is far more sensitive to brightness than to colour, so a good differ converts each pixel to a perceptual colour space (YIQ) and weights brightness most heavily. That is what this tool does, using the same formula as the pixelmatch library.

The threshold decides how large that perceptual distance has to be before a pixel counts as changed. It runs from 0 to 1:

• 0.0 to 0.05: extremely strict. Catches everything, including anti-aliasing noise and image compression artifacts.
• 0.1: the default, and the right starting point for most pages. Ignores rendering noise, catches real layout and colour changes.
• 0.2 to 0.4: forgiving. Use it on pages with photos, video posters, or heavy gradients where small shifts are expected.
• Above 0.5: only major changes register. Useful for a quick smoke check, but it will miss subtle regressions.

Compare staging against production, or before against after a deploy

The most common comparison is an environment check: your production URL in the first field, your staging or preview URL in the second. Any highlighted region is a difference your next deploy will introduce. Vercel, Netlify, and most CI platforms give every branch its own preview URL, which makes this a two paste job.

The second common comparison is time based: capture a baseline of an important page now, keep the result, then run the same page again after you ship. Because both captures use the same viewport and the same wait time, the only differences you see are the ones you actually caused.

It also works across sites entirely. Comparing your landing page with a competitor's is a fast way to see how differently the two pages use the same fold, and comparing a page in two languages catches text that overflows its container after translation.

When pixel diffing gives false positives

Pixel comparison is honest to a fault: it reports every difference, including the ones you don't care about. These are the usual sources of noise, and what to do about each:

• Animations and carousels: a slider on a different frame reads as a huge change. Increase the wait time so the animation settles, or compare a page state without it.
• Dates, timers, and counters: anything showing the current time will differ on every run. Expect a small permanent diff in that region.
• Ads and third party embeds: rotating creative changes on every load. Our renderer strips common ad and cookie overlays, which removes a lot of this.
• Font loading: if a web font arrives after the screenshot, the whole page reflows. A longer wait time fixes it.
• Lazy loaded images: content below the fold may not have loaded yet on a full page capture. Increase the wait, or compare the viewport only.
• Anti-aliasing: text edges render fractionally differently between runs. This is exactly what the threshold is for; leave it at 0.1 or higher.

How to automate screenshot comparison in CI

Once you know which pages matter, the manual loop becomes a script. The pattern is the same in every stack: capture a baseline, store it, capture the candidate on each build, diff the two, fail the build if the difference crosses your threshold.

Playwright and Puppeteer can both take the screenshots themselves, but that is where most teams get stuck. Headless Chrome in CI renders fonts differently from your laptop, cold containers produce different scroll positions, and cookie banners appear in one environment and not the other, so the diff is full of noise that has nothing to do with your code.

Pointing the capture step at a hosted rendering API solves that by making every screenshot come from the same environment with the same viewport and the same cleanup applied. The ScreenshotRender API takes a URL and returns the image from a single GET request, so the capture half of your pipeline is one line and the diff half stays whatever library you prefer.

Free and open source visual regression tools

If you want to run the comparison yourself rather than in a browser tab, these are the libraries worth knowing. All of them are free:

• pixelmatch: a tiny, fast pixel level differ in JavaScript with anti-aliasing detection. The comparison on this page uses its colour distance formula.
• Resemble.js: image comparison in the browser with tunable tolerances for colour, brightness, and ignored regions.
• BackstopJS: a full harness that manages baselines, scenarios, and an HTML report, built on headless Chrome.
• Playwright: has visual comparison built in through toHaveScreenshot(), including baseline management, if you already run Playwright tests.
• odiff: a fast native differ, useful when you are comparing large full page captures in CI and speed matters.

Watching competitor and landing pages for changes

Screenshot comparison is not only a testing tool. Running the same page against a saved capture on a schedule is how you notice that a competitor changed their pricing, reworked their hero, or quietly removed a plan. It is also how you catch a marketing page that broke because a CMS edit went wrong, without anyone reporting it.

For a one off check, comparing the two URLs here is enough. For continuous monitoring you want the capture step on a schedule, which is exactly what a screenshot API is for: hit the endpoint from a cron job, diff against the last capture, and alert yourself when the change is bigger than your threshold.

If you only need the capture rather than the comparison, the full page screenshot tool renders the entire scrollable page in one image.