Percy vs Chromatic

These two are rarely a straight swap, because they disagree about something more fundamental than features: what a visual test is a test of. Chromatic tests components from your Storybook stories. Percy tests whatever your existing test suite drives a browser to. Pick the wrong one for your codebase and the pricing comparison never becomes relevant.

At a glance

The capture model is the real difference

Everything else follows from this, and almost no comparison explains it.

Percy uploads the DOM. Your test runs in your browser, Percy serialises the DOM, CSS and assets, ships them to its cloud, and re-renders there. The upside is genuine: one capture can be re-rendered at several widths without re-running your suite, which makes responsive coverage unusually cheap. The downside is that Percy's renderer, not your browser, decides the final pixels — so what you approve is not literally what your test saw.

Chromatic renders in its own cloud too, but from your built Storybook rather than from a serialised DOM. It runs a standardised browser environment that watches for loading, painting and reflow to choose the capture moment — which is a determinism strategy rather than a comparison one, and a good one. It also archives the DOM, styling and assets at capture time, so you can inspect the code behind a change in your own browser rather than re-running the suite to reproduce.

Neither captures in the browser your tests actually ran in. If that matters to you — and for teams debugging environment-specific rendering it does — the local-capture tools are a different category; see Chromatic vs Argos.

Baselines: where Chromatic is genuinely ahead

This is the least-discussed and most operationally consequential difference, so it is worth the detail.

Chromatic keeps baselines alongside git history. Each branch maintains its own; a new branch inherits from the commit it was cut from; and accepted baselines travel with a merge. It detects squash and rebase merges through git provider APIs rather than relying on git alone, because those operations destroy the commit its last build was tied to.

Percy's model is simpler: compare the feature branch against main. That is adequate for linear workflows and starts to strain on telescoping pull requests, or when you merge one feature branch into another. Chromatic's own comparison page makes this criticism, and on the mechanics it is fair — though it is worth noting that Chromatic's more sophisticated algorithm brings its own edge cases, above.

Full treatment of the general problem in managing visual test baselines.

Cost at realistic volumes

Chromatic's pricing is published so it can be modelled. Percy's cannot, which is itself a planning fact.

The TurboSnap column is the one that decides most bills, and it is widely misunderstood — see the next section. Percy's equivalent table cannot be built from public information.

TurboSnap: how it really works, and what breaks it

TurboSnap analyses your git history and your Webpack or Vite dependency graph to find which story files a change can affect, then copies the unchanged snapshots rather than recapturing them. When no story's dependency graph changed at all, the build is bypassed entirely and bills zero snapshots. That is a genuinely strong piece of engineering and the reason Chromatic's headline allowances stretch roughly fivefold.

Four things in Chromatic's own documentation will surprise you, and none appear on their comparison page:

1. 01The dependency graph decides, not the nature of the change. Their docs are explicit: editing a file in a story's dependency graph prevents the bypass "even when the edit cannot affect the UI" — adding a comment counts.
2. 02A change to a global Storybook file triggers a full rebuild. Touch preview.js and every story is recaptured, because global files can change how any story renders.
3. 03Merge commits pull changed files from both ancestors, so a merge can capture considerably more than the work you did.
4. 04Rebase, squash and force-push break the computation. The commit tied to the last build no longer exists, so TurboSnap searches for a "replacement build" and approximates.

The practical consequence: a team that rebases heavily, or that touches preview.js regularly, will see far less TurboSnap benefit than the marketing multiplier suggests. Model your bill on your actual git habits, not on 5x.

Parallelisation and speed

Chromatic includes unlimited parallelisation on every tier, including free. Percy meters it — you buy a number of parallels, and Chromatic's comparison page is right that the unit is not clearly defined in concurrent-process terms.

The axis neither of them competes on

Both tools require you to author the coverage. With Percy that means a snapshot call in a test you wrote; with Chromatic it means a story someone maintained. In both cases, a page nobody wrote a test or story for is invisible, and coverage decays at exactly the rate team discipline does.

That is not a criticism unique to these two — it is true of every tool in our full roundup except the route-discovering ones. But it is the factor that most reliably predicts whether a visual programme is still running in a year, and no comparison page in this category treats it as a dimension. It is also the problem we built VisualMax to remove, which you should weigh accordingly — though we are not alone in trying: a whole category of tools now generates its own coverage, by recording sessions, driving an agent, or discovering routes.

So which one?

1. 01Do you have a well-maintained Storybook? If yes, Chromatic is very likely the answer and the rest of this page is detail. If no, Chromatic means building one first — a larger project than choosing a visual testing tool.
2. 02Do you need a number you can budget against? Chromatic publishes one. Percy does not, currently.
3. 03Do you rebase or squash heavily? Discount the TurboSnap multiplier substantially.
4. 04Is your risk on composed pages rather than components? Neither is ideal; Percy is closer, and page-level tools are closer still.