Open source visual regression testing tools in 2026

Open source visual regression testing tools capture screenshots of your UI and diff them against committed baselines, entirely in your own infrastructure with no per-snapshot cloud bill. They are the right starting point for most teams: free, in your control, and good enough for a long time. This is a shortlist of the ones worth using in 2026, what each is best at, and the one thing they all leave you to build yourself.

The trade in open source visual testing is always the same. You get the capture-and-diff engine for free and you keep every screenshot in your own pipeline, which is real value. What you do not get is the layer around it: hosted baselines, a review UI to approve or reject a change, history across builds, flake handling, and a verdict on whether a diff is a real regression or an intended change. With an open source tool, a visual change surfaces as a failed test and the judgment is yours. For this post we pushed one CSS change, a price that wraps onto a second line, through Playwright, BackstopJS, reg-cli, and Lost Pixel. All four flagged it, Playwright and Lost Pixel at about 3% of the pixels and BackstopJS at 5.72%, and none of them could say whether the wrap was intended. That is fine at small scale and expensive at large scale, and it is the exact seam hosted tools sell against.

Playwright's built-in toHaveScreenshot is the default answer for most teams in 2026. It is already in your test runner, it screenshots a page or element and diffs it against a baseline committed next to the test, and mask, threshold, and maxDiffPixelRatio tame the noise. The catches are the cross-OS baseline problem (a screenshot taken on macOS will not match one taken on your Linux CI, so you generate baselines in a container), baselines living in your repo, and a change arriving as a bare failed assertion with no history or review UI. See Playwright visual testing and fixing flaky Playwright screenshot tests.

BackstopJS is the long-standing standalone option. It drives Puppeteer or Playwright, captures a configured list of scenarios, diffs them, and generates an HTML report of the differences. It is free, flexible, and self-contained, with scenarios described in a config file rather than in your test code. The trade-off is that you maintain that config and infrastructure, and the report is a local artifact, not a hosted review workflow with approvals and history.

reg-suit is a capture-agnostic diff-and-report layer. It does not take screenshots itself; you point it at a directory of images your own tooling produced, and it diffs them against a stored baseline set, publishes an HTML report, and can comment on the PR. Baselines live in cloud storage you own, typically an S3 bucket. It pairs well with a capture tool like Storycap for Storybook, and it is a good fit when you want a report and PR comment but want to own the whole pipeline.

Loki is Storybook-focused: it captures every story and diffs it against a baseline, running Chrome either through Docker for consistency or locally. If your components already live in Storybook and you want a free way to catch visual changes per story, Loki is a direct fit. As with the others, you own the baselines and there is no hosted review layer. For the hosted end of the Storybook spectrum, see Storybook visual regression testing without Chromatic.

Lost Pixel's open-source core captures Storybook, Ladle, and pages and diffs them in your CI, with baselines in your repo or an S3 bucket. One important caveat in 2026: the Lost Pixel team joined Figma and is sunsetting the hosted platform, and the GitHub repository was archived on April 22, 2026. The OSS core still runs (version 3.22.0 caught our test change), but it is now read-only. Use it if you want its exact model and are comfortable maintaining an unmaintained dependency; if you were on the hosted platform, see the best Lost Pixel alternatives.

Below the tools sit the primitives, and it is worth knowing them. pixelmatch and Resemble.js are the pixel-comparison libraries most of these tools use internally, and jest-image-snapshot wires pixelmatch into Jest so a screenshot becomes a toMatchImageSnapshot() assertion. If you want the absolute minimum, you can build a homegrown visual check on these directly, but you are then reimplementing baseline management, reporting, and flake handling that the tools above already solved.

Open source is the right default until the review workload, not the capture, becomes the bottleneck. That happens when the volume of diffs is high enough that a human clicking through failed assertions is the slow step, when flakes have trained the team to rubber-stamp the check, or when coding agents are opening the pull requests and there is no human to triage every screenshot. At that point what a hosted tool sells is the layer open source leaves to you: hosted baselines and history, flake handling at capture time, and a verdict on each change. UI Verify is that layer over the same tests you already run - it replays your Playwright, Storybook, and Vitest suite, an AI judge classifies each change and holds the PR on a regression, and your agent can triage the diffs over MCP. It is free for 10,000 snapshots a month, so you can see whether the review layer is worth it before you pay, and open-source projects get a larger free tier of 50,000 snapshots a month, self-declared at sign-up with no approval and no card (see free for open source). See visual testing, build vs buy for the full trade-off.

For most teams it is Playwright, because it is already in your stack and needs no new infrastructure. Choose BackstopJS or reg-suit when you want a standalone, page-level pipeline you fully own, and Loki when your components live in Storybook. All of them are genuinely good, and the honest signal to move to a hosted tool is not that open source stopped working - it is that triaging the results became the job.