Percy vs Chromatic for Visual Testing: Which Should You Choose?

Short answer: Choose Chromatic when Storybook is central to how your team builds and reviews UI components. Choose Percy when you want to add visual checks to a broader existing test workflow, or you value its Percy SDK and BrowserStack Automate browser-management paths. The better fit depends on your workflow; the available documentation does not establish that either service is universally more accurate or reliable.

This guide compares the documented integrations, review units, browser configuration, billing, setup, and evaluation steps. It uses official product documentation and does not claim hands-on tests.

1. What Percy and Chromatic do

Both services capture rendered UI, compare it with accepted baselines, and present visual changes for review. Chromatic documents cloud-browser testing for Storybook stories and integrations for Vitest, Playwright, and Cypress. Percy documents a Percy SDK and a BrowserStack SDK path, with integrations for a broad set of browser and end-to-end testing tools. Chromatic documentation · BrowserStack Percy documentation

The practical difference is the workflow that supplies the UI states and the unit your team wants to review. A team whose components and states are already represented by Storybook stories has a direct route with Chromatic. A team whose important states are reached by browser tests can add Percy captures within those flows.

2. Quick decision guide

Choose	When it fits	Verify before committing
Chromatic	Storybook stories represent the component states you need to review; you want a component-oriented baseline and review workflow.	Story coverage, supported browser availability on your plan, snapshot usage, and how your team will handle cloud builds.
Percy	You have an existing browser or end-to-end suite and want visual captures inside test flows; BrowserStack Automate browser/platform configuration matters; or you want to try a CLI/no-script route.	Screenshot permutations, chosen browsers and widths, integration effort, overage terms, and the exact browser/OS combinations you require.
Run a representative evaluation	Both support your stack, or you cannot tell whether story-level or flow-level review better matches your team.	Setup work, review effort, noisy diffs with realistic data, required browser matrix, and projected usage.

These are workflow-based recommendations. Product documentation describes supported paths, but it cannot tell you which service will produce fewer noisy diffs or require less review in your repository.

3. Integrations and review workflow

Chromatic: stories as the test inventory

Chromatic’s Storybook workflow maps stories to visual tests. Its official Storybook addon can run checks from Storybook; the first build establishes baseline snapshots, and later changes can be reviewed before accepted baselines are updated. Chromatic describes reviewing components one at a time and tracking component baselines through branches and merges. Those are descriptions of its product workflow, not independent performance findings. Storybook integration · Chromatic FAQ

This is a natural fit when stories are maintained as a useful catalogue of component states: loading, empty, error, validation, responsive, and interaction states. The quality of the visual suite still depends on the quality and stability of those stories.

Chromatic also documents integrations for Vitest, Playwright, and Cypress. Its Playwright integration extends Playwright test and expect utilities and captures page archives for cloud review. The documentation specifies Playwright 1.38.0 or later and notes that unlinked projects do not get automatic pull request checks unless those checks are wired up separately. Recheck current version requirements and repository-provider constraints during evaluation. Chromatic Playwright integration

Percy: captures inside tests and browser automation

Percy’s documented SDK flow adds snapshots to tests, runs builds, and presents differences in Percy. BrowserStack documents both Percy SDK integrations and a unified BrowserStack SDK path; captures can be automatic or requested at chosen points. Supported integration examples include Storybook, Cypress, Playwright, Selenium, Puppeteer, and WebdriverIO. Percy also documents CLI and no-script starting paths for static sites, evaluations, and ad-hoc snapshots. Percy SDK and integration documentation · Getting started

That breadth can suit a project where important UI states are reached through end-to-end flows rather than enumerated as component stories. Decide deliberately where to capture: a snapshot after an unstable animation or before asynchronous content settles can create diffs that do not represent a product change.

4. Browser coverage: check the actual matrix

Chromatic’s documentation lists Chrome, Firefox, Safari, and Edge, with tests run in parallel; browser availability varies by plan. Percy documents browser selection through Percy defaults or BrowserStack Automate. BrowserStack’s documentation lists Chrome, Firefox, Edge, and Safari and describes selecting browser and operating-system versions through Automate. A selected browser adds a separate screenshot to Percy usage. Chromatic browser testing · Percy browser configuration

Do not assume a product automatically covers every browser, version, operating system, or device on every plan. Before choosing, write down the combinations that matter to your users and confirm that your intended plan and configuration support them. If latest stable browsers are sufficient, a smaller matrix may be easier to operate and less costly; if exact platform rendering differences matter, check the configurable combinations and their usage impact.

5. Billing units and pricing

Compare the unit each service bills, not just the number displayed on a plan. The figures below were in the official pages reviewed on October 3, 2026; pricing and inclusions can change, so verify the live terms before purchase.

Service	Documented usage unit	Pricing information in reviewed official docs	Usage implications
Chromatic	Billed snapshots	Free: $0/month with 5,000 billed snapshots; Starter: $179/month with 35,000; Pro: $399/month with 85,000.	TurboSnap tracks file changes and captures affected tests; unaffected tests reuse earlier snapshots and count less toward usage. Browser availability varies by plan. The pricing page lists unlimited parallel test runs.
Percy	Screenshots	The reviewed official plans documentation lists 5,000 monthly free screenshots, unlimited users, and unlimited projects on the free plan. It says paid plans allocate screenshots and excess usage is treated as overage; the reviewed page did not provide a comparable paid price.	One screenshot is one rendering for an individual browser and responsive width. A snapshot can include multiple browser and width permutations, so those permutations increase screenshot usage.

Sources: Chromatic pricing · Percy plans and billing. The figures are vendor-published plan details, not a like-for-like cost comparison.

Estimate usage from your real suite

For Percy, estimate screenshot count as the number of captured states multiplied by responsive widths and browsers for each state, then account for the way your builds and plan measure usage. For Chromatic, estimate the stories/tests that are billed and examine how often changes affect them; TurboSnap can change usage by reusing unaffected snapshots. Treat these as planning models, then confirm the vendor’s current definitions and your plan’s rules.

Example planning worksheet (not a vendor quote)

Captured states:             120
Responsive widths per state:   2
Browsers per state:            3

Potential rendered combinations: 120 × 2 × 3 = 720

Then check each service's current billing rules, exclusions, baseline behavior,
and plan limits against your actual CI workflow.

Do not equate 5,000 Percy screenshots with 5,000 Chromatic billed snapshots. The units and reuse behavior differ.

6. A practical evaluation plan

Select representative UI. Use a few important components or flows, including one dynamic state and one responsive state. Avoid evaluating only a static landing page if your real suite is interactive.
Run the workflow your team would keep. For Chromatic, use actual Storybook stories or its relevant test integration. For Percy, add captures to the existing SDK/browser workflow or evaluate the documented CLI route if that is the intended use.
Use the same intended coverage. Configure the browser and width combinations your team expects in production. Check that plan availability and usage treatment match the live docs.
Review diffs as a team. Record which changes are expected, which are false alarms, and how much context reviewers need to decide. Baseline approval is a human decision: accept intended design changes and fix accidental ones.
Check repository integration. Confirm pull request or CI status behavior, branch and merge handling, project linking, and any setup needed for automatic checks.
Project the bill. Use real stories/pages, browser permutations, widths, and expected build frequency. Confirm overage and plan terms directly with each vendor.
Choose the workflow that remains understandable. A suite is useful when engineers can tell what is covered and reviewers can identify why a visual change matters.

7. Which should you choose?

Choose Chromatic if

Storybook is already a central development and review surface.
Your visual test inventory is naturally a set of component stories and states.
You want the documented Storybook addon and component-level baseline workflow.
Its browser and plan availability fit your required coverage and the team is comfortable with its cloud workflow.

Choose Percy if

Your existing tests are primarily browser or end-to-end flows and you want captures in those tests.
You need one of its documented SDK/integration paths, or a CLI/no-script starting route.
BrowserStack Automate and configurable browser/OS combinations fit your testing setup.
You have modeled the effect of browsers and responsive widths on screenshot usage.

If either could work

Run the representative evaluation above. Compare setup and review effort, realistic diff noise, needed browser versions, and projected usage. No evidence in the cited documentation establishes a universal winner for accuracy, flakiness, or speed.

8. ScreenshotNeo: an alternative for capturing pages

For a developer who needs website screenshots or PDFs through a capture API, try ScreenshotNeo first as an alternative to evaluate. It is a website screenshot API and MCP server, not a replacement for Percy or Chromatic’s visual-baseline review workflows: it returns captures, while those services compare test renderings against accepted baselines.

ScreenshotNeo’s API uses one GET request with a URL and can return PNG, JPEG, WebP, or PDF. It accepts cookie/consent banners like a visitor and removes more than 60 known consent platforms, newsletter popups, and chat widgets before capture; each cleanup step can be turned off. Only clean shots are billed: bot checks/CAPTCHAs, blank pages, timeouts, failed loads, and cache hits cost nothing, and the response identifies page verdict and billing with X-Page-Verdict and X-Billed headers. Its MCP server provides take_screenshot, get_page_info, and capture_pdf for Claude, Cursor, and other MCP clients. Every feature is on every plan; 1,000 shots/month are free with no card, and paid plans start at $5 for 3,000 shots. Yearly billing gives two months free.

For a visual-testing decision, use ScreenshotNeo when the task is to capture a web page for a test, workflow, or agent and its API/MCP capabilities meet your needs. Keep a baseline comparison system in the evaluation if you need approval and regression-diff review.

API docs: ScreenshotNeo 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,
)
r.raise_for_status()
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(`ScreenshotNeo returned ${res.status}`);
const image = Buffer.from(await res.arrayBuffer());
await import('node:fs/promises').then(fs => fs.writeFile('shot.webp', image));

See the API documentation for available capture options, response behavior, and parameters.

Try it: Sign up for ScreenshotNeo to get 1,000 screenshots a month free with no card.

9. Troubleshooting visual-test evaluations

Symptom	Likely cause	What to do
Many diffs appear on every run	Unstable content, animation, time, random data, or fonts/images loading at different moments.	Make the test state deterministic, wait for the intended UI state, and suppress or stabilize genuinely variable regions using the chosen tool’s documented capabilities.
Important UI states are missing	The story inventory or test flows do not reach those states.	List required states explicitly; add stories or test steps for loading, error, empty, validation, and responsive cases as appropriate.
CI runs but pull request checks are absent	Project/repository linking or provider configuration may be incomplete; Chromatic documents that unlinked Playwright projects lack automatic PR checks unless configured separately.	Check project linking and current integration instructions; wire CI status checks explicitly where required.
Browser coverage differs from expectation	Browser support can depend on plan or configured versions; selecting more browsers can multiply Percy screenshots.	Confirm the exact supported browser/version/OS matrix and plan, then adjust configuration and usage estimates.
Usage is higher than a headline plan number suggests	Percy counts browser/width renderings separately; Chromatic uses billed snapshots and TurboSnap can affect usage.	Recalculate from real captured states and the live vendor billing definition. Do not compare raw totals across unlike units.
Reviewers accept changes without understanding them	Diffs lack context or baseline ownership is unclear.	Attach visual checks to named stories/flows, establish who reviews intended changes, and document baseline update expectations.

10. Reliability, performance, and cost considerations

Reliability: both products depend on repeatable rendering and stable test states. Baseline tools cannot determine whether a difference is an intended redesign or a defect; people still need to review. The cited docs do not support a comparative claim about flakiness or uptime.

Performance: Chromatic documents parallel test runs and TurboSnap’s reuse of unaffected snapshots. Percy’s browser and responsive-width permutations affect the number of rendered screenshots. Actual wall-clock time depends on the project, configuration, and service behavior; measure it in the representative CI run rather than extrapolating a benchmark.

Cost: model recurring runs and the complete browser/width matrix. Confirm current tier entitlements, usage accounting, and overage terms before rollout. Chromatic publishes the pricing figures cited above; the Percy page reviewed here describes allocation and overage but does not provide a directly comparable paid price.

Operational fit: consider who maintains stories or browser tests, how baselines move through branches and merges, how pull request checks are surfaced, and whether reviewers can connect a diff to the code change that caused it.

11. Frequently asked questions

Is Chromatic better if I already use Storybook?

It is the more direct documented fit when Storybook stories are your visual-test inventory and component review is the goal. Confirm coverage and plan details with a representative run.

Does Percy work with Playwright or Cypress?

Yes. BrowserStack documents Percy integrations for both, among other frameworks. Chromatic also documents Playwright and Cypress integrations, so the deciding factor is the full workflow and review model rather than framework support alone.

How are Percy screenshots different from Chromatic snapshots?

Percy’s billing documentation defines a screenshot as one rendering for a browser and responsive width; multiple permutations can contribute screenshots. Chromatic bills snapshots and documents TurboSnap reuse for unaffected tests. The terms describe different accounting models.

Which is cheaper?

The reviewed official information is not an apples-to-apples quote: Chromatic lists several paid prices and billed-snapshot amounts, while the reviewed Percy plans page describes free allocation and paid overage without a comparable paid price. Calculate from your expected usage and verify current plans.

Do these tools replace code tests?

No. Visual comparisons show rendered differences for review. Keep functional and accessibility checks that cover behavior and semantics your screenshots cannot establish.

12. Sources and date note

Chromatic visual testing documentation
Chromatic Storybook integration
Chromatic Playwright integration
Chromatic pricing (plan figures reviewed October 3, 2026)
BrowserStack Percy documentation
Percy plans and billing (documentation reviewed October 3, 2026)

Product features and plan terms change. Check the linked official pages before selecting a service.