Chromatic vs Percy for Website Visual Regression Testing

Chromatic is a strong starting point when your team builds and reviews components in Storybook. Percy is worth evaluating when you want visual checks integrated with existing test and CI workflows, or need its documented BrowserStack Automate workflow for selected devices and browsers. The right choice depends on what you capture, your review process, required browser coverage, and how each service counts usage.

Both tools compare rendered captures with approved baselines and show visual changes for review. They complement functional tests: a visual diff can reveal an appearance change, but does not establish that behavior works or that a page is accessible. See the Chromatic documentation and Percy documentation for their current workflows.

1. How visual regression testing works

A team captures a rendering as a baseline. On later builds, the tool captures the updated UI, compares it with the baseline, and presents differences for review. The baseline and review workflow help a team decide whether a change is expected and should be accepted or investigated.

The unit under test might be a component state, a whole page, or a page reached through a test flow. A baseline comparison only helps if the captures are stable and representative. Randomized content, unstyled flashes, changing remote resources, or slow-loading content can create noisy differences. Keep test data deterministic and make the capture wait for the UI state you intend to check.

2. Chromatic vs Percy at a glance

Decision area	Chromatic	Percy	Question for your team
Best initial fit	Component-centered work modeled in Storybook. Its documentation also describes Vitest, Playwright, and Cypress integrations.	Visual checks connected to a range of test frameworks and existing CI workflows; also supports a Percy-on-BrowserStack-Automate project type.	Are you validating component states, full pages, or user flows?
Baselines and review	Chromatic describes baselines that follow Git branches and merges, with hosted build review.	Percy documents baseline management and grouped snapshot review.	Does the branch and approval workflow match your repository practices?
Browser and device coverage	Chromatic describes coverage of latest stable common browsers. Its coverage percentage is a vendor claim.	Web projects offer browser selection; the Automate project type supports specified desktop and mobile OS, devices, and browsers.	Are common desktop browsers enough, or do you need explicit device and OS combinations?
Execution and investigation	Chromatic advertises parallelization and archived DOM, styles, and assets for inspection.	Percy documents visual review and root-cause analysis features. Check current execution limits for the plan you consider.	What feedback time do you need, and how will reviewers investigate a diff?
Usage unit	Chromatic’s comparison page presents a snapshot allowance; confirm its current terminology and plan limits.	Percy counts a rendered page or component for an individual browser and responsive width as a screenshot.	Have you estimated rendered combinations rather than only test cases?

Product descriptions in this table come from vendor documentation. In particular, performance, coverage, and cost comparisons on Chromatic’s own head-to-head page are vendor claims, not independent measurements. Review current official plan pages before deciding: pricing and limits can change.

3. When Chromatic is the better fit

Start with Chromatic if your team already maintains Storybook and wants visual review tied closely to stories and component changes. This approach makes it natural to cover component states without first building full-page flows for every variant. Chromatic also documents integrations with Vitest, Playwright, and Cypress, so a Storybook-centered workflow is not its only documented route.

Your team treats Storybook as a source of truth for UI components and their states.
Reviewers want to inspect changes in a hosted build workflow aligned with branches and merges.
You want the test subject to be an isolated component state, not just a page-level outcome.

Before adopting it, confirm that the stories cover the states users care about and that dynamic data is controlled. A component library can have broad state coverage while still missing page-level layout problems or interactions between components.

4. When Percy is the better fit

Evaluate Percy when visual checks should connect to an existing test suite and CI workflow across different test frameworks. If your team needs selected browser or device combinations through BrowserStack Automate, check the documented Percy-on-Automate project type and verify that it covers the exact environments you need.

You already have page or browser tests and want to add visual snapshots in that workflow.
Your coverage needs span multiple supported frameworks or existing CI jobs.
You need explicit browser, operating system, or device combinations available through the relevant Percy project type.

Confirm how your repository branches map to baselines and how grouped snapshot review will fit your approval process. Test the flow with a representative feature branch and merge before rolling it out broadly.

5. Estimate screenshot usage before comparing plans

Do not equate a test case or snapshot with one billed screenshot. BrowserStack’s Percy billing documentation defines a screenshot as a page or component rendered for an individual browser at a specific width. One snapshot can therefore result in multiple screenshots.

For example, two pages × two browsers × three responsive widths = 12 screenshots, even if the interface displays two snapshots. For a first-pass monthly estimate, use:

monthly screenshots = pages_or_components × states × browser_width_combinations × runs_per_month

Then refine the estimate for retries, branch builds, and any other workflow that triggers captures. Determine whether the selected plan includes enough volume and what overage terms apply. BrowserStack’s official Percy billing documentation, accessed October 3, 2026, lists 5,000 free screenshots per month and unlimited users and projects on its free plan. Treat these as dated vendor-published figures and recheck the live plan details.

Chromatic’s comparison page, updated August 2026, listed $179 per month with 35,000 included snapshots. This is a Chromatic-published comparison figure, not an independently verified current price. Check Chromatic’s current pricing and snapshot definitions directly before using it in a budget.

6. Run a fair evaluation

Choose a representative slice. Include a few component states, at least one full page or flow if relevant, and the browsers or widths your team actually supports.
Stabilize the rendering. Use deterministic fixtures, predictable fonts and assets, and a clear ready state. Avoid capturing during an unstyled flash or while content is still shifting.
Use the same change set. Run both candidates against the same base and feature branch changes, with equivalent capture scope and environment.
Review the whole workflow. Compare setup effort, feedback time, baseline updates, branch behavior, diff investigation, and how easily a developer can determine whether a change is intentional.
Model volume and cost. Count page or component × state × browser/width combinations for the expected run frequency, then compare with current included usage and overage terms.
Decide using team needs. Prefer the workflow that gives your reviewers trustworthy diffs and fits your test subjects and required environments.

7. Reliability, performance, and cost considerations

Keep comparisons reliable

Fix test data and timestamps where possible so content does not change randomly between runs.
Wait for the specific UI state you want to compare, rather than relying on an arbitrary short delay.
Watch for font loading, image loading, animations, and asynchronous content that can shift pixels after capture.
Separate expected design changes from unexplained diffs and review baseline updates deliberately.

Set realistic feedback expectations

Both services describe cloud capture and review workflows, but the research sources do not provide an independent, comparable benchmark for execution speed. Measure your representative build, including queueing and review time, instead of relying on a vendor performance claim. Chromatic advertises unlimited parallelization; confirm the current plan and practical workflow details that matter to your build.

Budget rendered work

Usage grows with the number of tested subjects, states, browser and width combinations, and runs. A small initial suite can become expensive or slow if every branch runs a broad matrix. Begin with high-value states and environments, then expand based on observed visual risk and the current billing model.

8. Troubleshooting common visual test problems

Symptom	Likely cause	What to do
Many diffs appear on an unchanged page	Random data, changing timestamps, animations, remote content, or unstable assets.	Use fixed fixtures, disable or settle animations where appropriate, and make external content deterministic.
Layout differs between runs	Capture begins before fonts, images, or asynchronous UI have settled.	Wait for the relevant selector or application-ready state and ensure required assets load before capture.
Component snapshots miss a page-level defect	The test scope covers isolated stories but not composition or navigation.	Add representative page or flow captures alongside component-state checks.
Usage is higher than expected	Each browser and responsive width rendering contributes to screenshot volume.	Count the full matrix and run frequency; reduce redundant combinations or target high-value states.
A baseline behaves unexpectedly on a branch	Branch and merge behavior does not match team expectations.	Check the service’s current baseline rules and test a branch-and-merge cycle in a small project.
Diffs are hard to diagnose	The capture lacks context about the source change or relevant DOM and styling state.	Use the service’s available inspection and root-cause tools, and keep the snapshot set focused enough for review.

9. ScreenshotNeo as an alternative for clean website captures

If your need is to capture website screenshots for reports, monitoring, content workflows, or an AI agent, rather than maintain an approved-baseline visual regression workflow, try ScreenshotNeo first. It is a website screenshot API and MCP server. Its clean-capture flow accepts cookie and consent banners like a visitor, then removes more than 60 known consent platforms, newsletter popups, and chat widgets; each step can be turned off. Only clean shots are billed: bot checks and CAPTCHAs, blank pages, timeouts, failed loads, and cache hits cost nothing, with the response identifying the outcome in headers.

One GET request returns PNG, JPEG, WebP, or PDF. For API options and parameter details, see the ScreenshotNeo API documentation.

curl -G "https://api.screenshotneo.com/v1/shot" -d access_key=YOUR_API_KEY --data-urlencode url=https://stripe.com -o shot.webp

import requests

r = requests.get(
    "https://api.screenshotneo.com/v1/shot",
    params={"access_key": "YOUR_API_KEY", "url": "https://stripe.com"},
    timeout=90,
)
open("shot.webp", "wb").write(r.content)

const q = new URLSearchParams({ access_key: 'YOUR_API_KEY', url: 'https://stripe.com' });
const res = await fetch(`https://api.screenshotneo.com/v1/shot?${q}`);
if (!res.ok) throw new Error(`Screenshot request failed: ${res.status}`);
await Bun.write('shot.webp', res);

ScreenshotNeo also offers an MCP server for AI agents, including Claude, Cursor, and any MCP client, with tools for taking screenshots, getting page information, and capturing PDFs. It supports full-page and selector captures, device presets and custom viewports, PDF settings, custom CSS and JavaScript, wait conditions, request blocking, headers and cookies, caching, signed links, asynchronous jobs, bulk capture, and a usage API. Those capabilities support capture workflows; they do not by themselves provide the baseline comparison and visual review workflow described above.

Free includes 1,000 screenshots a month with no card. Paid plans start at $5 for 3,000; yearly billing gives two months free, and every feature is on every plan. Sign up free for 1,000 screenshots a month, with no card required.

10. Frequently asked questions

Do Chromatic or Percy replace functional tests?

No. They compare appearance. Keep functional tests for behavior and use accessibility checks for accessibility requirements.

Can I use both services?

A team can evaluate or operate multiple tools, but decide whether the extra capture and review workflows add enough value to justify their maintenance and usage.

Which one should a small team try first?

If the product UI is already organized in Storybook, begin with Chromatic. If visual checks need to attach to an existing multi-framework test workflow, evaluate Percy. In either case, test a representative slice before committing to broad coverage.

Is a Percy snapshot the same as one screenshot?

No. A snapshot can generate several screenshots across browser and responsive-width combinations.

Sources

Chromatic documentation and Chromatic FAQ.
Chromatic’s comparison page; comparative claims there are vendor-authored.
BrowserStack Percy documentation and Percy plans and billing.