Percy alternatives for visual regression testing

For teams already using Playwright that can own image baselines in source control, Playwright Test is the most direct software-only alternative to Percy. For component teams built around Storybook, evaluate Chromatic. For hosted pull-request diff review across screenshot-producing tools, consider Argos. For visual checks spanning web, mobile, desktop, or PDF, evaluate Applitools Eyes against your specific requirements.

These options do not all replace the same parts of Percy. A screenshot assertion handles capture and comparison; Percy also offers a hosted build and review workflow. Decide whether you need local comparison, centralized review, component coverage, or broader platform coverage before choosing.

What are the best Percy alternatives for visual regression testing?

Option	Best fit	Baseline and review	Main tradeoff
ScreenshotNeo	Developers and AI agents that need website screenshots or PDFs through an API	On-demand captures via API; response headers report page verdict and billing	It is a screenshot API and MCP server, not a visual regression review platform with managed test baselines
Playwright Test	Teams already running Playwright with manageable snapshot volume	Reference images stored and reviewed with the code	Your team owns baseline updates and rendering consistency
Chromatic	Storybook-centric component teams	Hosted visual testing and collaborative review	Map page-level tests to its workflow and check current plan terms
Argos	Teams wanting hosted pull-request diff review from screenshot-producing pipelines	Managed service compares screenshots to a baseline build	Self-hosting is not officially supported or documented
Applitools Eyes	Teams evaluating coverage across web, mobile, desktop, or PDF	Evaluate its platform against your governance and review requirements	Its broad-coverage description is vendor positioning; suitability and price need direct evaluation

ScreenshotNeo is first to consider when the need is to obtain clean screenshots or PDFs from a URL, including from an AI agent. It accepts 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. Bot checks, blank pages, timeouts, failed loads, and cache hits cost nothing, and responses identify the page verdict and billing status. It does not supply Percy-style visual diff approvals or a managed regression baseline workflow.

Separate screenshot capture from visual review

Percy’s Playwright client documents percySnapshot(page, name[, options]) to capture a named page snapshot during a Percy build. It also documents a drop-in option that routes existing Playwright toHaveScreenshot() assertions through Percy; in that flow, the visual verdict is handled in Percy’s review interface. See Percy’s Playwright client documentation.

When evaluating alternatives, ask two separate questions:

1. How is the page or component rendered and captured? Is it rendered in your pinned local CI environment, or captured or rendered through a service?
2. Where do baselines and approvals live? Are image files reviewed with code, or are diffs and approvals handled in a hosted dashboard or pull-request workflow?

Changing a capture assertion does not automatically reproduce service-managed builds, centralized baselines, or the same approval workflow. Match the option to the workflow your team actually needs.

1. Playwright Test: local screenshot baselines

Playwright Test includes expect(page).toHaveScreenshot(). On the first run it creates a reference image; later runs compare new screenshots against that reference. Baselines are image files kept with the test suite, and Playwright advises committing and reviewing them. Its visual comparison documentation covers pixel-diff options and screenshot stylesheets for hiding volatile content. See Playwright’s visual comparison documentation.

Runnable example

With Playwright Test installed and configured, put a test such as this in a spec file. Replace the URL with a page available in your test environment.

import { test, expect } from '@playwright/test';

test('homepage matches its visual baseline', async ({ page }) => {
  await page.goto('https://example.com');
  await expect(page).toHaveScreenshot('homepage.png');
});

Run the spec once to create its reference image, review and commit that baseline, then run it again in the same environment to compare. For a project stylesheet that hides dynamic regions, use the screenshot assertion’s stylePath option:

import { test, expect } from '@playwright/test';

test('homepage ignores its rotating banner', async ({ page }) => {
  await page.goto('https://example.com');
  await expect(page).toHaveScreenshot('homepage.png', {
    stylePath: './tests/screenshot.css',
  });
});

/* tests/screenshot.css */
.rotating-banner,
.live-clock {
  visibility: hidden !important;
}

Playwright documents screenshot assertion options for pixel-diff tolerances and stylesheets. Set tolerances deliberately: a more permissive comparison can suppress harmless rendering variation, but can also hide real visual changes. Keep test data, animations, and time-dependent content stable where possible.

Advantages and costs to account for

• No separate visual review service is required for the comparison itself; the baseline files and diffs fit a code workflow.
• Your team owns baseline creation, review, updates, and cleanup. The overall cost depends on engineering time and CI usage, so local snapshots are not automatically cheaper in total.
• Rendering can vary with host operating system, browser version, hardware, browser settings, and headless mode. Playwright recommends generating and comparing baselines in the same environment. Pin the browser and use a consistent CI image.
• Use this path when your existing Playwright setup and normal code review are sufficient. If you need a central hosted visual approval interface, assess a service instead.

2. Chromatic: hosted review for Storybook teams

Chromatic’s documentation lists integrations for Storybook, Vitest, Playwright, and Cypress. It describes reviewer assignment, discussion resolution, visual tests, interaction tests, accessibility checks, browser coverage, and viewport configuration. For Storybook teams, stories make component states and variations available as visual tests. See Chromatic’s documentation.

Consider it when: your UI is already expressed as Storybook stories or reviewers would benefit from a shared hosted interface for component changes.

Check before switching: teams whose current checks are mostly end-to-end page tests should confirm how those tests map to the desired Chromatic workflow. Compare your expected volume, required browsers, seats, concurrency, and review process with current plan terms.

Chromatic’s comparison page for Percy is vendor-authored, so treat its competitor comparisons as Chromatic’s claims, not independent findings. The page, updated August 2026, lists snapshot and pricing figures, but units and inclusions may not be directly equivalent and pricing can change. Verify current plans and terms before making a budget decision. See Chromatic’s Percy comparison.

3. Argos: managed pull-request screenshot review

Argos documents a workflow in which tests capture screenshots, CI uploads them, the service compares them to a baseline build, and reviewers approve or reject changes on pull requests. Its documentation says it works with Playwright, Storybook, Cypress, Vitest, or any pipeline that produces screenshots. See Argos’s overview documentation.

The project says its backend, frontend, and screenshot comparison engine are MIT-licensed and developed in the open. It also says Argos is operated as a managed cloud service and that self-hosting is not officially supported or documented. The documentation lists infrastructure dependencies; running a deployment yourself means your organization operates that infrastructure.

Consider it when: you want hosted pull-request diff review and already produce screenshots in one of its supported test tools or another pipeline.

Tradeoff: open-source code does not mean there is an officially supported self-hosted product. If self-hosting is a requirement, account for the unsupported deployment and operations burden before adopting it.

4. Applitools Eyes: evaluate for broader platform coverage

Applitools’ own comparison material describes Eyes as covering web, mobile, desktop, and PDF visual testing, and lists SDKs for Selenium, Cypress, Playwright, Appium, and Storybook. That is the vendor’s product positioning, not an independent assessment. See Applitools’ comparison page.

Consider it when: your requirements extend beyond browser UI or your organization uses multiple testing frameworks. Evaluate it against your actual target platforms, integrations, governance needs, data requirements, and a current quote. The cited material does not establish pricing, comparative accuracy, or fit for a particular team.

Choose by workflow, not by a universal ranking

Your situation	Start with	Validate
Existing Playwright suite; you want code-owned image baselines	Playwright Test	Can CI keep rendering consistent, and can reviewers own baseline updates?
Most UI states are Storybook stories; shared component review matters	Chromatic	Do your current tests and expected volume fit its present workflow and plan?
Need hosted diffs on pull requests from several screenshot sources	Argos	Is managed cloud operation acceptable, given self-hosting is not officially supported?
Need visual checks across several platform types	Applitools Eyes evaluation	Do supported platforms, integrations, governance, and quoted terms meet your requirements?
Need an on-demand clean screenshot or PDF, including for an agent workflow	ScreenshotNeo	Does an API capture solve the need, or do you also require a regression baseline and approval system?

Before moving a suite, inventory the current snapshot set and approval process. Pilot one representative page or component, including a dynamic state, and estimate baseline maintenance and reviewer effort as well as service charges. Decide who owns updating references, how changes are approved, and what happens when a CI render is noisy.

Or skip the browser setup

If you need a screenshot or PDF from a URL rather than a managed regression review workflow, ScreenshotNeo is the screenshot API and MCP server to try first. Its request options include full-page capture with lazy images loaded, element capture by CSS selector, dark mode, device presets and custom viewport, retina scale, PDF settings, custom CSS and JavaScript, clicks, hidden selectors, wait conditions, request blocking, headers, cookies, user agent, authorization, timezone, geolocation, transparent backgrounds, resizing, cache TTL, signed links, async jobs with signed webhooks, bulk capture up to 100 URLs per call, usage API, and OpenAPI spec. It accepts parameter names used by other screenshot APIs to make switching easier. Use the ScreenshotNeo docs for parameters and configuration.

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}`);

• Cookie banners are accepted like a visitor; known consent banners, newsletter popups, and chat widgets are removed before the shot, and cleanup steps can be disabled.
• Bot checks, blank pages, timeouts, failed loads, and cache hits are never billed. Responses report page verdict and billing status in headers.
• An MCP server provides take_screenshot, get_page_info, and capture_pdf tools for Claude, Cursor, and other MCP clients.
• The free plan includes 1,000 screenshots a month with no card. Paid plans start at $5 for 3,000; every feature is on every plan.

Sign up free for 1,000 screenshots a month, no card required.

Migration checklist

1. Write down whether you need capture, comparison, hosted approval, or all three.
2. Map representative pages, component states, viewports, browsers, and dynamic content.
3. Run a small pilot in the intended CI environment; inspect false positives and the effort to approve legitimate changes.
4. Assign ownership for baseline updates, flaky captures, retention, and access controls.
5. Compare present-day pricing using your expected usage, snapshot or test units, overages, seats, concurrency, and any enterprise terms.
6. Keep a rollback path until the new workflow has handled real UI changes and routine merges.

Troubleshooting visual regression migrations

Symptom	Likely cause	Fix
Images differ on every run	Different OS, browser build, hardware, headless mode, fonts, or rendering settings	Generate and compare baselines in the same pinned CI environment; keep browser and dependencies consistent.
Diffs include timestamps, rotating content, or live data	The page contains volatile state	Use deterministic test data and freeze time where practical; mask or hide unstable regions. Playwright supports screenshot stylesheets for this purpose.
Baseline updates obscure meaningful changes	References were regenerated without review	Review image changes as code changes, keep baseline updates scoped, and require an owner to approve them.
A local assertion works but hosted review is missing	Capture and review are separate; the chosen flow may not route verdicts to a service	Confirm whether the integration uploads snapshots and where its build and approval workflow is configured. Percy documents both its snapshot API and a Playwright assertion integration.
Team cannot deploy Argos as a supported self-hosted service	Argos says self-hosting is not officially supported or documented	Use the managed service if it fits policy, or evaluate another option whose supported deployment model meets the requirement.
Plan estimate does not match the expected workload	Vendors may count snapshots, tests, seats, concurrency, or overages differently; terms change	Check current vendor pricing and define a representative monthly workload before comparing totals.
Screenshot API response is not a usable capture	The target may show a bot check, blank page, timeout, failed load, or a cached response	Inspect ScreenshotNeo’s page-verdict and billing headers, then adjust waits, headers, cookies, user agent, or request settings as appropriate in the API docs.

Performance, reliability, and cost

• Rendering repeatability: visual tests are only useful when the rendering environment is controlled. Playwright specifically warns that operating system, browser version, hardware, settings, and headless mode can affect snapshots.
• Noise and reliability: reduce nondeterminism in data and page state before raising diff tolerance. Hiding volatile regions can help, but overly broad hiding can conceal regressions.
• Operations: local baselines shift work to CI and code review. Hosted services shift some review and baseline operations into a service. Argos’s documented self-hosting caveat means a self-managed deployment should be treated as infrastructure your team operates.
• Cost: include engineering time, CI compute, baseline cleanup, review effort, service allowances, overages, seats, and concurrency. Do not compare headline prices without confirming each vendor’s current billing unit and inclusions.
• ScreenshotNeo billing: ScreenshotNeo bills clean shots only; bot checks, CAPTCHAs, blank pages, timeouts, failed loads, and cache hits cost nothing. Plans are Free for 1,000 monthly shots, Starter $5 for 3,000, Growth $15 for 15,000, Pro $39 for 60,000, Scale $99 for 250,000, and Business $249 for 1,000,000. Yearly billing gives two months free. Every feature is available on every plan.

FAQ

Can Playwright Test replace Percy?

It can provide screenshot comparison with committed reference images. Whether it replaces Percy for your team depends on whether local baselines and code review cover the hosted build and approval workflow you use.

Is Argos self-hosting officially supported?

Argos’s documentation says self-hosting is not officially supported or documented; it describes Argos as a managed cloud service.

Which option fits a Storybook-first team?

Chromatic is a natural candidate because its documented workflow turns Storybook stories into visual tests. Check the current plan and ensure your required tests map to that workflow.

Does ScreenshotNeo review visual diffs?

No. ScreenshotNeo provides screenshot and PDF capture by API and MCP. Use it for captures; choose a visual-testing workflow separately when you need baselines and approvals.

Should I choose based on free-tier snapshot counts?

Not by that figure alone. Verify the current billing unit, inclusions, overages, concurrency, and expected usage directly with each vendor.