Storybook visual regression testing in 2026

If you are following a guide written before 2026, it almost certainly tells you to use the Storybook test-runner. That advice is now out of date.

That reshuffles the options. Here is the current landscape.

Your options

Chromatic: the path of least resistance

Built by the Storybook team, and the integration is correspondingly tight. The free tier is 5,000 billed snapshots per month — and because TurboSnap copies unchanged snapshots rather than recapturing them, that stretches to roughly 25,000 turbosnaps. Every tier includes unlimited projects, collaborators, and parallel runs.

npx storybook add @chromatic-com/storybook
npx chromatic --project-token=<your-token>

The catch to know before you standardise on it: the free tier is Chrome only. Safari, Firefox and Edge require the Starter plan at $179/mo. If the reason you want visual testing is a Safari rendering bug, the free tier will not tell you about it.

TurboSnap is the cost lever

TurboSnap analyses which stories a change actually affects and copies the rest rather than recapturing. On a large library it is the difference between a free tier that lasts a week and one that lasts a month — enable it before concluding the pricing does not work.

Loki: the open-source equivalent

MIT-licensed with around 1.9k stars and actively maintained. It captures your stories through Chrome — in Docker, on AWS Lambda, or locally — and also targets iOS simulators and Android emulators, which is unusual at this layer.

npm i -D loki
npx loki init

# Capture references, then test against them.
npx loki update
npx loki test

Docker rendering is the important part: it makes results reproducible across operating systems, which is exactly the problem that sinks most self-hosted visual setups. What you give up is the review workflow — approving a change is a CLI operation, with no place for a designer to weigh in.

Vitest browser mode: the current runner

Storybook's recommended runner is now the Vitest addon, which runs stories as Vitest tests in a real browser. It does not itself do visual comparison — it runs and asserts. Visual capability comes from a companion addon, and several exist: storybook-addon-vrt, storybook-addon-vis, and @storycap-testrun/browser among them.

npx storybook add @storybook/addon-vitest

This is the most actively moving part of the ecosystem right now, and the addons vary in maturity. Check each one's recent commit history before adopting it — this space has already lost one significant player, with Lost Pixel archived in April 2026 when its team joined Figma.

What story-level coverage misses

This applies to every option above equally, and it is the most important thing to understand about Storybook-based visual testing.

1. 01Coverage equals story coverage. A component with no story is invisible. A state nobody wrote a story for — the error banner, the twelve-item overflow, the very long name — is untested.
2. 02Isolation hides composition bugs. A button can render perfectly in its story and still overlap a heading on the settings page, because the bug lives in how components combine, not in either component.
3. 03Stories use fixture data. Real pages get real data: longer strings, missing fields, unexpected nulls. Those are exactly the inputs that break layouts.
4. 04Nobody writes a story for a page. Which means the routes your customers actually load are not what you are testing.

None of this argues against Storybook testing — for a design system it is the right tool and catches genuine regressions cheaply. It argues against treating it as complete coverage. The distinction is developed in what is visual regression testing.

The pragmatic pattern is both: story-level checks for the component library, and page-level checks on the routes that carry revenue.