ScreenshotNeo

BlogComparisons

BackstopJS vs Chromatic for UI Regression Testing

Compare BackstopJS and Chromatic for UI regression testing: how baselines, setup, review, and ownership differ, plus which workflow may fit your team.

By the ScreenshotNeo team4 October 202611 min read

BackstopJS and Chromatic both compare rendered interfaces with visual baselines, but they put different parts of the workflow in your hands. BackstopJS is an open-source, scenario-driven workflow: you configure captures, run them, inspect differences, and approve accepted screenshots as new references. Chromatic is a managed cloud service built around UI snapshots, with Storybook as its most direct workflow and documented integrations for Vitest, Playwright, and Cypress.

Choose BackstopJS if you want direct control over URLs, viewports, scripts, and reference files and can maintain the browser and review workflow. Choose Chromatic if hosted browser execution and collaborative change review fit your team, especially if you already use Storybook. These are workflow recommendations based on the projects’ documentation, not results from a performance benchmark or hands-on comparison. BackstopJS documentation, Chromatic visual testing documentation, and Chromatic quickstart.

1. What differs between BackstopJS and Chromatic?

Decision BackstopJS Chromatic
Operating model Open-source npm package. Your team configures and runs captures and manages the baseline workflow. Managed cloud service. Its documentation describes uploading UI or test artifacts and running snapshot comparisons in cloud browsers.
What defines a test Explicit scenarios with URLs, viewports, selectors, readiness conditions, and optional interaction scripts. Storybook stories are a natural unit because they capture component states. Documentation also describes Vitest, Playwright, and Cypress integrations.
Baseline ownership Reference screenshots are part of the project workflow; backstop approve promotes accepted captures. Snapshots are compared with baselines and changes are reviewed through Chromatic’s hosted workflow.
Browser execution The README describes Puppeteer as the default and Playwright support for Chromium, Firefox, or WebKit. Docker is an optional execution approach. Chromatic documents cloud browser infrastructure and browser and viewport choices.
Other documented checks The reviewed documentation centers on screenshot comparison and configured scenario interactions. Product documentation describes visual, interaction, and accessibility testing. These capabilities do not guarantee that every defect will be detected.
Operations and cost The software is distributed as an npm package; your team still owns execution and workflow setup. A service with plans and usage terms to verify directly. Current prices and quotas were not established in the sources reviewed for this guide.

In either workflow, a baseline is an accepted rendering that later captures are compared against. A detected difference is evidence to review, not automatically a bug: intended design changes also alter pixels.

2. How BackstopJS works

BackstopJS defines the pages and states you want to capture as scenarios. A scenario can specify a URL and viewport and can use selectors, readiness conditions, or interaction scripts for the state you want represented. You run captures against the existing references, inspect the generated differences, then approve changes that should become the new references.

The basic documented command sequence is:

npx backstop init
npx backstop test
npx backstop approve
  1. init creates the initial configuration and scenarios, including the URLs and viewports to capture.
  2. test captures the configured scenarios and compares them with reference images.
  3. Review the differences. Investigate unexpected changes and accept only the intended ones.
  4. approve promotes accepted latest captures to the reference set.

The exact generated configuration and available options depend on the installed BackstopJS version and selected engine. Use the project README as the source of truth for configuration fields, selectors, readiness, scripts, engine settings, reports, and Docker options: BackstopJS README.

When BackstopJS is a good fit

  • Your checks are naturally described as pages or routes, viewports, and browser interactions.
  • You want reference screenshots under your project’s control and an explicit approval step.
  • You are prepared to maintain consistent browser execution, CI setup, storage, and a way for people to review diffs.
  • You need to configure scenario setup rather than make Storybook stories the center of the testing model.

What your team owns

BackstopJS provides the capture and comparison workflow, while your team supplies the operating conventions around it: where and when to run it, how to keep rendering environments consistent, how to share reports and images, and who can approve a baseline update. The repository documents CI compatibility and optional Docker execution. Its repository page also asks for a new maintainer or owner, so check current project status and support expectations before making it a long-term dependency; the available research does not establish a release cadence or support commitment.

3. How Chromatic works

Chromatic’s quickstart describes creating a project, building and uploading Storybook, and running tests. Stories provide repeatable component states to snapshot, while the hosted workflow presents changes for review. This can make it a direct match for teams whose UI is already organized and exercised through Storybook.

Chromatic documents integrations beyond Storybook, including Vitest, Playwright, and Cypress. Storybook is still the most direct fit described in the research because stories capture component states. Storybook’s Visual Tests addon lists Storybook 7.6 or later as a prerequisite for that addon specifically; do not assume that prerequisite applies to every Chromatic integration. See the Chromatic quickstart, visual testing docs, and Storybook Visual Tests addon page.

When Chromatic is a good fit

  • Your team already maintains Storybook stories for important components and states.
  • You prefer hosted browser execution and a collaborative review workflow.
  • You use Vitest, Playwright, or Cypress and want to assess the documented Chromatic integration for your particular setup.
  • You want to investigate the documented combination of visual, interaction, and accessibility checks.

Before adopting a hosted service, check its current pricing, quotas, supported configuration, and data and security terms directly. Those details can change and were not verified for this article.

4. Which is better for UI regression testing?

Neither is universally better. The better choice is the one that matches how you define UI states and who should own execution and review.

If this matters most Start with Reason
Explicit page and viewport scenarios BackstopJS Its configuration is centered on URLs, viewports, selectors, readiness, and interaction scripts.
Owning reference files and approval conventions BackstopJS Its documented workflow includes project-owned references and a command to approve new ones.
Existing Storybook coverage Chromatic Stories are a natural unit in the documented snapshot workflow.
Hosted execution and collaborative review Chromatic It provides a managed cloud workflow for snapshots and review.
Existing Vitest, Playwright, or Cypress workflow Evaluate Chromatic Chromatic documents integrations with those tools; confirm that the current integration supports your requirements.
Direct control over execution setup BackstopJS You configure and maintain the capture environment and workflow.

Do not choose based on an assumed speed, false-positive rate, reliability level, or total cost: the reviewed sources do not provide a comparable benchmark for those claims. Instead, list the UI states that matter, decide where browser execution should happen, and map out who will review and approve changes. Then check current product terms and project status.

5. Can Chromatic work without Storybook?

Yes, according to Chromatic’s documentation: it describes integrations for Vitest, Playwright, and Cypress as well as its Storybook workflow. Storybook remains the most direct fit when your component states already live in stories. For a non-Storybook project, evaluate the integration for your test runner and confirm its current supported configuration in the official docs. Do not apply the Storybook Visual Tests addon’s Storybook 7.6-or-later prerequisite to every integration; that requirement is listed for the addon.

6. Is BackstopJS self-hosted?

BackstopJS is an open-source npm package that your team installs and runs, and its reference-image workflow is project-managed. In practical terms, you own the execution environment and the surrounding process. Its README also describes optional Docker rendering, which can help align capture environments. Verify current engine and configuration details in the README.

7. How to make visual regression checks dependable

  1. Choose representative states. Capture the routes, components, and interaction states where a visual regression would matter. Avoid adding scenarios that nobody will review.
  2. Make state repeatable. Use documented readiness conditions and interaction scripts where needed so the capture reaches the intended state before comparison.
  3. Keep the rendering environment consistent. Browser engines, viewport choices, and execution environments affect rendered output. BackstopJS documents Puppeteer by default, Playwright engine support, and optional Docker; Chromatic documents cloud browser execution and browser and viewport choices.
  4. Review diffs as changes to explain. Determine whether a difference is an intended update, an unexpected regression, or a capture-state inconsistency before changing a baseline.
  5. Approve deliberately. In BackstopJS, promote accepted captures with backstop approve. In Chromatic, use the hosted review workflow for detected changes.
  6. Check live project and service details. Confirm BackstopJS maintenance expectations and Chromatic’s current pricing, quotas, supported configurations, and data terms before adopting either.

8. Edge cases to account for

  • Delayed or stateful pages: A screenshot taken before the target content is ready can differ from a correct baseline. Configure suitable readiness or interaction steps and verify that they reach the expected state.
  • Viewport-dependent layout: A page can behave differently at each viewport. Define the viewports that reflect your supported layouts instead of treating one capture as representative of all sizes.
  • Component state coverage: A story or scenario only protects the state it actually captures. Include meaningful states such as relevant interactions or content variations in the chosen workflow.
  • Browser rendering differences: Different engines or environments can produce different output. Keep the capture environment aligned over time and review any change to its configuration alongside resulting diffs.
  • Intentional design changes: A large diff can be correct. Review and accept a new baseline only when the UI change is expected.
  • Tooling requirements: The Visual Tests addon’s stated Storybook version requirement applies to that addon, not automatically to all Chromatic integrations. Check the specific integration you plan to use.

9. Performance, reliability, and cost

The official sources reviewed do not establish comparative run times, false-positive rates, service uptime, or a total-cost figure. Avoid treating either workflow as faster or more reliable without measuring your own scenarios in the configuration you intend to run.

  • BackstopJS operating cost: It is an npm package, but the team must operate the browser execution, CI workflow, reference storage, and review process. Docker is a documented option to reduce rendering differences across environments.
  • Chromatic service cost: Current plan prices and usage quotas were not verified here. Check the live plan and usage terms for your project before estimating spend.
  • Reliability practices: Whichever tool you choose, keep capture state and execution configuration repeatable, make baseline approval reviewable, and investigate whether a diff comes from an actual UI change or a different capture environment.
  • Scope the comparison: Compare the effort and terms for the same set of routes or component states, viewports, browser choices, CI runs, and review expectations.

10. Troubleshooting visual regression workflows

Symptom Likely cause What to do
Many unexpected differences appear together The browser, viewport, or execution environment changed, or the page did not reach the same state. Check the capture configuration and readiness steps first. Keep browser and viewport choices consistent, then inspect the resulting differences.
A capture shows incomplete or transient content The scenario was captured before the desired page state was ready. Review the scenario’s readiness condition or interaction sequence and confirm it reaches the state you intend to compare.
A change is visible but unclear whether to accept The diff mixes intended design changes with possible regressions. Review the relevant UI change and the affected state; approve a new reference only for changes that are intended.
BackstopJS command or configuration behavior differs from the guide The installed version or chosen engine may not match the README details you followed. Check the current README and configuration for your installed version, including engine settings and any Docker use.
Chromatic setup does not match a Storybook tutorial The project may be using a non-Storybook integration, or an addon prerequisite may have been applied too broadly. Follow the documentation for the specific Vitest, Playwright, Cypress, or Storybook workflow you use. Treat the Storybook 7.6-or-later note as the Visual Tests addon requirement.
Chromatic usage or price is unclear Plan terms and quotas can change and were not established in the reviewed sources. Verify current pricing and usage terms directly with Chromatic before committing to a budget.
BackstopJS support expectations are unclear The research does not establish a current release cadence or support commitment; the repository asks for a new maintainer or owner. Review the current repository state and decide whether your team can maintain the workflow if needed.

11. ScreenshotNeo as an alternative for capturing pages

For teams that need website screenshots as part of a separate capture workflow, ScreenshotNeo is a website screenshot API and MCP server from Yorker Media. It can capture a URL as PNG, JPEG, WebP, or PDF. It is an alternative to try first when you want a screenshot service with consent-banner cleanup, explicit page-verdict and billing headers, or MCP tools for AI agents. It is not presented here as a replacement for BackstopJS or Chromatic’s visual-baseline review workflows.

Or skip the browser setup

Make one GET request to capture a page. See the ScreenshotNeo API documentation for the available parameters.

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, and more than 60 known consent platforms, newsletter popups, and chat widgets are removed before the shot. Each step can be turned off.
  • Bot checks or CAPTCHAs, blank pages, timeouts, failed loads, and cache hits cost nothing. Responses include X-Page-Verdict and X-Billed 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 per month with no card. Paid plans start at $5 for 3,000 screenshots; every feature is on every plan.

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

12. FAQ

Do BackstopJS and Chromatic replace manual UI review?

No. Their documented workflows surface visual changes for comparison and review. A person still needs to decide whether a change is expected.

Does Chromatic only test pixels?

Chromatic’s product documentation describes visual, interaction, and accessibility testing. Those are documented capabilities, not a guarantee that every issue will be caught.

Which tool gives me more control over reference screenshots?

BackstopJS documents project-owned reference images and an explicit approval command. Chromatic documents hosted snapshots and review.

Can I choose Chromatic based on its price here?

No current price or quota was verified for this article. Check Chromatic’s current plans and usage terms directly.

Is there a verified speed winner?

No comparable performance benchmark was found in the sources used for this guide. Measure your own representative workflow if run time is a deciding factor.

Sources