A BackstopJS alternative for the agent era

BackstopJS is a config-driven, open-source visual regression tool: you list scenarios in a JSON file, it captures each one in a headless browser, diffs it against a committed reference image, and writes an HTML report with a reference, test, and diff view you can scrub between. It is free, it runs locally or in your own CI, and it has been dependable for years. I am building an alternative to it, so read this with that in mind. But I want to start with what it does well, because I ran it this week.

Three scenarios against uiverify.ai, one desktop viewport, the default Puppeteer engine. The reference run took nine seconds, the test run five, and the report opened in a browser tab.

That is a lot of value for a JSON file. It also ships real knobs for stable shots: delay and ready selectors for timing, hideSelectors and removeSelectors to drop noisy elements, a misMatchThreshold to tune sensitivity, and an official Docker image so renders match across machines. For a small, stable suite that one or two people maintain, it is a clean setup with very little to explain.

Here is what BackstopJS adoption looks like now. A team pulls it in, points it at the branch versus the integration branch, and has Claude read the output: the agent reads the diff and reports what changed and what looks broken. Another team runs it by hand for the before-and-after of a component-library migration and has not yet tried letting the agent see the comparison. Both are days into it, both are happy with it, and both are already asking the same next question.

So the category no longer needs a pitch. People want the screenshots diffed, and they will wire an agent to the diff themselves. The contest is what happens after the diff exists: who reads it, who decides whether the change was intended, and who holds the pull request when it was not.

Everything below follows from BackstopJS being a developer-only local CLI. That is not a flaw; it is what a free, local, config-driven tool is. The friction shows up once pull-request volume climbs, because the part it leaves to you, reading and triaging the diff, is the part that does not scale with agent-written PRs.

• No hosted review surface. The report is a local artifact. The media company's lead named this as his main ask: product owners and designers are not used to developer tools, and he wanted them to be able to open the review. The agency lead could not show me his report at all, because it only exists on the machine that ran the command.
• No verdict. Claude can tell you that a small percentage of pixels differ. It cannot tell you whether that difference was the restyle you asked for or the badge that fell off, unless something feeds it the pull request's intent alongside the crop.
• PR integration is yours to build. The check, the gate, the comment on the PR: all DIY.
• Determinism is manual. The knobs are there, and you configure and maintain them per scenario, rather than getting a frozen clock, neutralized animations, and seeded randomness by default.
• Baselines live in your repo and grow with the suite, and someone owns re-referencing them after every intended change.

Instead of generating a report for a human to open, UI Verify sends per-story diffs and a verdict on each to your coding agent over MCP, cropped to the region that moved rather than a whole-page bitmap. That crop matters more than it sounds. If you hand an agent a full page and ask whether it looks broken, it will usually say no, even when a badge is half off the screen. The AI judge labels each change intended or regression by reading the PR description, and the PR is held on a regression. The agent that wrote the change accepts the intended baselines from the terminal; see triage with your agent.

I built it this way because of my own workflow: I usually have at least three agents changing UI in parallel, and what I want is to be confident none of them broke anything without opening each page myself. Existing tools gave the agent no way in. Capture is Storybook-independent, so it replays the Storybook, Playwright, or Vitest tests you already run, and it also captures real pages. Determinism is handled at render time, then the flakes that remain are auto-ignored; the mechanics are in deterministic captures.

• Your suite is small and stable and the diff count per PR is low. The report is fine at that volume.
• Everything must be free and fully local, with no external service in the loop. BackstopJS is the right tool, full stop.
• The job is episodic: a component-library migration where you eyeball one batch of diffs and move on. This is exactly what the agency lead uses it for, and I would too.

• Parallel agents open PRs faster than a human reads diffs.
• A shared component changes and the blast radius spans dozens of stories or pages.
• You want the diff read and triaged by the agent, and the PR held only when it is a real regression.
• Someone outside engineering needs to open the review.

The free tier is 10,000 snapshots a month, 50,000 for open source, so trying it next to BackstopJS is not a purchase decision. If you are weighing whether to keep building on a local tool, build vs buy for visual testing walks through the arithmetic, and the setup skill wires the first captures.