Chromatic alternatives for teams not using Storybook

If your team does not use Storybook, you can still do visual regression testing. If you already use Playwright Test, its built-in screenshot assertions let you capture pages and compare them with reference images committed to your repository. If you want cloud capture, shared review, or hosted baseline management, evaluate Chromatic’s Playwright or Cypress integrations and other hosted services against your actual test workflow. Playwright is a useful capture and comparison capability; by itself, it does not provide the same hosted team review workflow.

For teams that need screenshots from URLs for monitoring, documentation, or AI workflows rather than visual assertions inside browser tests, ScreenshotNeo is the first alternative to try: it removes common consent banners, popups, and chat widgets before capture, and only clean shots are billed.

1. Choose based on your existing test model

“Chromatic alternative” can mean two different things: a way to add image comparisons to tests you already run, or a hosted service that captures pages and gives a team a shared place to review visual changes. Decide which problem you need to solve before comparing products.

Need	Start with	What you own or evaluate
Visual assertions in existing Playwright end-to-end tests	Playwright Test toHaveScreenshot()	Reference images, a stable capture environment, and snapshot review in your repository workflow.
A hosted review workflow without making Storybook the source of tests	Chromatic’s Playwright or Cypress integration, if it fits your cases	Confirm supported integration details, capture model, review process, and plan limits with the vendor.
Story based component tests and cloud review	Storybook with its visual-testing addon and Chromatic	Adopting Storybook and maintaining stories as the visual test cases.
URL screenshots through an API or AI agent	ScreenshotNeo	Choose capture options and integrate a screenshot response; it is not a drop-in baseline-review system for Playwright assertions.

The practical decision is who will generate screenshots, store and update baselines, keep rendering consistent, and review diffs. Local assertions suit teams prepared to manage those jobs in version control and CI. A hosted workflow may be preferable when reviewers need to inspect changes without running the application locally.

2. Use Playwright Test screenshot assertions

Playwright Test’s screenshot assertion API is await expect(page).toHaveScreenshot(). On the first run, Playwright creates a reference screenshot. Later runs capture the page again and compare the result with that baseline. The snapshots belong in version control and should be reviewed when changed. See the Playwright visual comparisons guide.

Runnable example

Install Playwright Test and a browser, then create a test such as tests/home.visual.spec.ts:

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

test('home page visual baseline', async ({ page }) => {
  await page.goto('https://example.com');
  await expect(page).toHaveScreenshot('home.png', {
    fullPage: true,
    animations: 'disabled',
  });
});

Run the test once to create its baseline, then run it again to compare:

npx playwright test tests/home.visual.spec.ts
npx playwright test tests/home.visual.spec.ts

Review the generated snapshot file in your source control changes and commit it with the test when it is the intended baseline. On future changes, inspect the actual-versus-expected diff. If the design change is intentional, update the baseline with Playwright’s snapshot update option, review the changed image, and commit it with the code change. Do not automatically accept every changed screenshot in CI.

Test a stable state, not a moving target

A screenshot assertion is only as useful as the state it captures. Wait for the route and meaningful content to be ready, set deterministic test data, and avoid capturing clocks, random identifiers, rotating promotions, or animations unless those are what you intend to test. For an authenticated page, establish the test session before navigating to the page under test. Prefer selectors and application state that indicate readiness over arbitrary long sleeps.

test('account page visual baseline', async ({ page }) => {
  await page.goto('https://example.com/sign-in');
  await page.getByLabel('Email').fill('visual-test@example.com');
  await page.getByLabel('Password').fill('test-password');
  await page.getByRole('button', { name: 'Sign in' }).click();
  await page.getByRole('heading', { name: 'Account' }).waitFor();

  await expect(page).toHaveScreenshot('account.png', {
    fullPage: true,
    animations: 'disabled',
  });
});

Replace the example credentials and flow with test fixtures appropriate to your application. Avoid placing real credentials in test source or snapshots.

Useful assertion options

Option or pattern	Use	Trade-off
fullPage: true	Capture the whole scrollable page.	Long pages may take more time and can include more dynamic content.
animations: 'disabled'	Reduce animation-driven differences.	Use only if the static state is what you want to validate.
mask and maskColor	Cover volatile regions, such as a user-specific avatar, during comparison.	Masked regions can hide real regressions in those areas.
maxDiffPixels or maxDiffPixelRatio	Allow a bounded number or share of differing pixels.	Loose thresholds can let unintended visual changes pass.
stylePath	Apply test-only CSS, for example to hide an unstable widget.	Ensure the override does not mask the interface behavior you mean to test.
toHaveScreenshot(['top.png', 'bottom.png'])	Assert a sequence of screenshots when the page is scrolled or otherwise changed.	Each screenshot needs a meaningful, reproducible state.

Consult the Playwright assertion documentation for the current option details and types. Avoid assuming that a threshold makes the test robust: it is a policy for acceptable pixel differences, not a fix for inconsistent rendering.

Keep capture environments consistent

Playwright warns that screenshot output can vary with operating system, browser version, browser settings, hardware, power source, and headless mode. Generate and compare baselines in a consistent environment. A common team approach is to create and check baselines using the same CI image and browser installation used for comparison, rather than generating them on one developer’s machine and checking them on another platform. The exact setup depends on your CI system and is not prescribed by the visual-comparison guide.

3. Evaluate hosted options when shared review matters

Chromatic without a Storybook-first workflow

Not using Storybook does not, by itself, establish that Chromatic is unavailable. Chromatic’s own comparison page lists Playwright and Cypress connections in addition to Storybook. Check its current integration documentation and confirm that it supports your test cases, capture expectations, CI checks, and review workflow before deciding. This capability description comes from Chromatic, so treat the vendor’s page as the source for its integration claims: Chromatic documentation.

Ask whether your tests can supply the states you need, where capture happens, how branches and baselines are represented, who can review changes, and what happens when a visual check fails. A provider integration may change the workflow and operational responsibility compared with repository-managed Playwright snapshots; verify the specifics before migration.

Storybook plus Chromatic, if adopting Storybook is on the table

If the team is open to changing its test model, Storybook’s visual-testing workflow makes stories into visual tests through its addon. Storybook describes cloud capture, review and baseline acceptance in the addon, plus CI and pull-request checks. This is an adjacent option rather than a fit for teams committed to not using Storybook. See the Storybook visual testing guide. Storybook also documents importing stories into Playwright or Cypress end-to-end tests in its testing overview.

Other hosted platforms

Argos’s comparison, published July 16, 2026, describes Percy as uploading DOM for cloud rendering, Chromatic as rendering and capturing in its cloud, and Argos as capturing screenshots in the test browser before uploading them for diffing. These are vendor-authored comparative descriptions, not independent evaluation. Use them to frame questions for a shortlist, then verify the capture architecture and workflow in each provider’s current documentation. Different capture models can affect what code and environment the provider needs and where rendering differences arise.

Argos also reported specific prices in that comparison: $100/month for Argos Pro, $179/month for a stated 35,000-snapshot Chromatic tier, and a $599/month Percy entry tier. These are dated, vendor-reported figures and may reflect particular terms. They are not confirmed current official prices; check each provider’s pricing page for current limits, billing terms, and geography before budgeting. Source: Argos CI’s comparison.

4. Where ScreenshotNeo fits

ScreenshotNeo is a website screenshot API and MCP server from Yorker Media. It captures a URL as PNG, JPEG, WebP, or PDF with one GET request. It is useful when your job is to capture pages through an API, automate screenshots in an AI agent, or use a clean screenshot in a separate workflow. For Playwright visual assertions, it does not replace the test runner’s assertion and repository baseline workflow described above.

Its differentiators are concrete: before capture, it accepts cookie or consent banners like a visitor and removes more than 60 known consent platforms, newsletter popups, and chat widgets; each cleanup step can be turned off. Bot checks or CAPTCHAs, blank pages, timeouts, failed loads, and cache hits cost nothing, and response headers identify the page verdict and billing status. Its MCP server exposes take_screenshot, get_page_info, and capture_pdf for Claude, Cursor, and other MCP clients. All features are on every plan: 1,000 shots per month free with no card, then 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; annual billing gives two months free.

Call the screenshot API

See the ScreenshotNeo API documentation for the available parameters. Store your API key as a secret and substitute the target URL for https://stripe.com in these examples.

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

Use the service’s available options for cases such as full-page capture, a CSS-selected element, dark mode, device viewport and retina scale, PDF output, custom CSS or JavaScript, waiting for a selector or network idle, hiding selectors, blocking requests or resource types, custom headers and cookies, geolocation, timezone, transparency, resizing, cache TTL, signed public image links, asynchronous jobs with signed webhooks, and bulk captures of up to 100 URLs per call. The usage API and OpenAPI specification are also available. Parameter names used by other screenshot APIs work too, which can make switching easier. Consult the docs for parameter names, combinations, and response behavior.

For the do-it-yourself browser-test route, keep toHaveScreenshot() and manage baselines in your test workflow. For URL-to-image captures, the API call above avoids setting up a browser in your own project.

5. Make the choice with a small pilot

1. Pick representative cases. Include one stable page, one dynamic page, and any states that have caused review pain.
2. Define the review owner. Decide who can approve an intended visual change and who investigates a failed check.
3. Run a Playwright baseline pilot. Commit snapshots, run comparisons in a consistent environment, and measure the review and maintenance work your team actually takes on.
4. Evaluate hosted integration only against your requirements. Confirm supported runner and test coverage, branch and pull-request behavior, capture location, reviewer access, baseline history, and usage limits directly with the provider.
5. Compare ongoing costs fairly. Include CI compute, storage, engineering time for snapshot upkeep, and subscription or usage charges. The dated Argos comparison prices above are not a substitute for current quotes.
6. Choose the smallest workflow that meets the need. Keep page-level end-to-end assertions, component-state review, and general URL screenshot capture distinct when they solve different problems.

6. Troubleshooting visual diffs

Symptom	Likely cause	Fix
A baseline changes on another machine or in CI	Different OS, browser build, settings, hardware, or headless environment.	Generate and compare snapshots in a consistent environment; update baselines there.
Text or layout shifts intermittently	Fonts or content were not ready, or data changes between runs.	Wait for a meaningful ready state, use stable fixtures, and ensure required fonts and assets load before capture.
Large diffs appear around a clock, avatar, or feed	The test includes time-dependent or user-specific content.	Freeze or fixture the data when possible; otherwise mask a tightly scoped region and retain coverage of surrounding layout.
Animation causes inconsistent frames	The screenshot catches different animation points.	Disable animations for the assertion or wait for the intended stable state.
A full-page image contains unexpected content	Lazy-loaded content may appear only after scrolling, or the page changes while capture proceeds.	Use full-page assertion intentionally, make data deterministic, and check that the page’s lazy content is ready for the test.
Many snapshot updates appear in a code change	A shared style, dependency, browser, or baseline-generation environment changed.	Review representative diffs first, identify the common cause, then approve only expected changes.
A threshold hides a real regression	Pixel tolerance is too permissive or covers the wrong area.	Reduce the threshold and mask only the specific unstable content; thresholds do not correct nondeterminism.
A hosted integration does not cover the expected test	The selected integration or capture model differs from the team’s assumption.	Verify current vendor documentation and prove the exact route, state, and CI workflow in a pilot before migration.

7. Performance, reliability, and cost

Screenshot comparisons add browser work and produce image artifacts. Full-page captures, many states per test, and repeated CI runs can increase execution time and storage needs; focus first on high-value routes and states. Run captures in parallel only to the degree your CI capacity and application can handle without making test state unstable.

Reliability depends on controlling the rendered state and environment. Keep browser versions and operating systems consistent, isolate test data, wait for stable readiness signals, and make snapshot changes reviewable. A hosted service may provide shared history and review, but its exact capture, retention, and collaboration behavior must be checked in the current product documentation and plan.

There is no independent benchmark in the research for runtime, accuracy, or total cost across these products. For repository-managed Playwright assertions, account for CI compute, baseline storage, and maintenance. For hosted providers, verify current subscription, snapshot allowances, retention, and overage terms. For ScreenshotNeo, the stated plan prices are above; only clean shots are billed, as identified by the response’s X-Page-Verdict and X-Billed headers.

Or skip the browser setup

For a URL screenshot outside your Playwright assertion suite, ScreenshotNeo takes one API call:

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

Cookie banners, popups, and chat widgets are removed before the shot. Bot checks, blank pages, and failed loads are never billed. An MCP server lets AI agents take screenshots. The free plan includes 1,000 screenshots a month with no card; paid plans start at $5 for 3,000. See the API documentation and ScreenshotNeo, then sign up for 1,000 free screenshots a month with no card.

FAQ

Can I use Chromatic without Storybook?

Chromatic’s comparison page lists Playwright and Cypress integrations as well as Storybook. Check its current integration docs against your test cases and workflow before relying on that fit.

Is Playwright a complete replacement for a hosted visual-testing service?

It provides screenshot assertions and comparisons. Your team still manages repository baselines, capture consistency, and review; a hosted service may offer a shared workflow, depending on its current capabilities.

Should I use visual tests for every route?

Begin with high-value pages and states where visual regressions matter, then expand when the review and maintenance effort is sustainable.

Does ScreenshotNeo replace Playwright screenshot assertions?

No. ScreenshotNeo provides URL screenshot and PDF capture through an API and MCP server. Playwright assertions compare test captures with reference snapshots in your test suite.