Percy, Chromatic, Argos, Loki: visual regression in 2026

The four contenders

Percy (BrowserStack) has been in this market the longest of the four. It captures screenshots during your test runs — Playwright, Cypress, Selenium, or Storybook — uploads them to BrowserStack's cloud, and computes pixel diffs against a baseline. Review happens in the Percy web UI: you see the diff, approve or reject, and the PR status check updates. Percy supports snapshot comparison across multiple browsers from a single run, which is its most distinctive capability.

Chromatic is built by the Storybook team and integrates with Storybook more deeply than any other tool on this list. The unit of visual regression in Chromatic is a Storybook story — a component at a specific state — not a full page. Chromatic snapshots your stories in the cloud, presents diffs as a PR status check in GitHub, and has a review UI that lives alongside the pull request rather than in a separate application.

Argos is the open-source-friendly option. It integrates with Playwright and Cypress via a lightweight SDK, stores screenshots in its own cloud service, and surfaces diffs in the GitHub PR interface. The project has strong GitHub integration — the diff review experience feels native to the PR workflow rather than requiring a separate tool.

Loki is self-hosted and Storybook-aligned. No SaaS, no external screenshot storage — it runs locally or in CI, diffs screenshots against a local baseline directory, and reports results as pass/fail. The trade-off: you own baseline storage, baseline management, and any review UI on top of the command-line output.

The hidden cost: review fatigue

Before comparing features, there's an operational cost that no marketing page surfaces honestly: the human attention required to review visual diffs.

Every PR that changes CSS, layout, copy, or component state generates visual diffs. Those diffs need human review: is this change intentional or a regression? A component library refactor might produce 300 diffs across stories. A design system token update might affect 50 pages. A CSS global change might show up in screenshots across every test that captures any page.

Someone has to look at each diff and decide whether to approve it. At first, teams do this carefully. After a few weeks, they start pattern-matching. After a month, they're clicking through quickly without really looking. After two months, they're auto-approving everything. After three months, someone disables the visual tests because they're blocking PRs without providing signal.

Review fatigue is the primary reason visual regression programmes fail — not cost, not tooling failures. The mitigation is scope control: start with a small number of critical-path components or pages, not your whole application. The visual regression you can sustain reviewing is more valuable than comprehensive coverage you auto-approve.

Where Chromatic wins

For teams using Storybook, Chromatic is the clear pick. The integration is native — Chromatic was built alongside Storybook, reads stories directly, and requires no additional test instrumentation. Snapshots are triggered at the story level, which means diffs are scoped to the component that changed, not a full-page screenshot where you're hunting for what moved.

# Run Chromatic from CI
npx chromatic --project-token=$CHROMATIC_PROJECT_TOKEN

That's the complete integration for a Storybook project. No screenshot calls in test files, no additional SDK configuration. Chromatic reads your stories and handles the rest.

The review UI is the strongest of the four: side-by-side diffs with zoom, annotations, direct approval in the GitHub PR interface, and a concept of "accepted changes" that persists across subsequent PRs. Accepting a change from a PR means that diff is no longer flagged in future PRs unless it changes again.

Chromatic's pricing is snapshot-based (snapshots per month). For teams with large component libraries, costs scale with component count and change frequency. The starting tier is accessible, and the integration quality — for teams already on Storybook — justifies the spend.

Where Argos pulls ahead

For teams running Playwright E2E tests rather than Storybook stories, Argos offers the most friction-free integration:

import { argosScreenshot } from '@argos-ci/playwright';
 
test('checkout page visual regression', async ({ page }) => {
  await page.goto('/checkout');
  await page.waitForLoadState('networkidle');
  await argosScreenshot(page, 'checkout-page');
});

One function call captures and uploads the screenshot. The diff surfaces in the GitHub PR as a status check. The review interface is GitHub-native in a way that feels lighter than Percy's separate web application — diffs appear in a UI that lives inside the PR, not a separate product.

Argos is also the most pricing-accessible for small to medium teams. The open-source project tier is usable without a credit card. The paid team tier is competitive with Percy for comparable screenshot volumes.

For teams that want to start simple and grow from there: Argos on Playwright is the lowest-friction entry point into visual regression testing.

Where Percy still makes sense

Percy's differentiated capability is multi-browser snapshot comparison. You can run a single Percy snapshot command and receive diffs across Chrome, Firefox, Safari, and Edge. For teams that need to verify visual consistency across browsers — not just in the default browser — Percy is the only tool on this list that handles this natively.

Percy also makes sense for enterprise teams already in the BrowserStack ecosystem. If your team is paying for BrowserStack for cross-browser or device testing, Percy is included (or discounted depending on your contract), and the integration with the rest of the BrowserStack suite is cleaner than running multiple vendors.

The review UI is capable but requires a separate browser tab outside the GitHub PR flow. For teams comfortable with that, it's a non-issue. For teams who find context-switching to a separate review application disruptive, Chromatic or Argos's PR-native review experience is smoother.

Where Loki fits

Loki's use case is narrow and specific: teams with a Storybook component library and a hard requirement that screenshots not leave their infrastructure. Financial services firms, healthcare organisations, government agencies, and companies with data residency requirements that prevent sending UI screenshots to external cloud services.

If you're in that category, Loki is a real, functional option. The self-hosting requirement is a genuine constraint that the cloud tools can't satisfy. For everyone else, the operational overhead of managing your own baseline storage and review workflow is harder to justify when cloud tools handle it for single-digit dollars per month.

The advice that applies regardless of tool

Start with a smaller scope than feels right. Visual regression rewards restraint.

The teams with the healthiest visual regression programmes cover 5–15 specific things they care about most — the checkout flow, the design system's core button variants, the pricing table, the main navigation states — and cover those thoroughly. They don't try to snapshot every page. They don't run visual regression on every test.

The teams that try to cover everything tend to end up in the auto-approve pattern within a few months. The teams that start narrow maintain genuine review discipline because the diff volume is manageable.

Pick your tool based on your stack: Storybook → Chromatic, Playwright E2E → Argos, enterprise BrowserStack → Percy, self-hosted requirement → Loki. Then scope deliberately. Let the programme grow as your team develops the habit of reviewing diffs rather than clicking through them.