Component visual testing: an automated verification method that renders user interface components in isolation (outside the context of the full page) and compares their appearance with a validated reference state, in order to detect visual regressions at the design system level before they spread to production pages.
There is a question front-end teams carefully avoid asking: "our components are visually tested in Storybook, but are our production pages tested too?" In most cases, the answer is no. And that gap is expensive, because the visual bugs that reach your users don't live in Storybook. They live in real pages, with real data, real interactions, and real combinations of components.
Chromatic is an excellent tool for testing isolated components. Delta-QA is built to test full pages. For an introduction to visual testing, see our visual regression guide. They are not competitors in the strict sense: they are tools looking at the same problem from different altitudes. But if you have to pick just one, or if you want to understand what each brings, this comparison gets straight to the point.
All our comparisons, based on verifiable criteria: Alternatives and comparisons.
Chromatic checks isolated components; who tests your real pages in production? Delta-QA covers them without writing code, with a free account and no credit card. Try Delta-QA for free →
Chromatic: The Design System Guardian
Chromatic, created by the Storybook maintainers, is the natural extension of the Storybook ecosystem for visual testing. For an overview of visual testing applied to design systems, see our dedicated guide. The concept is brilliant in its logic: you have already defined your components in Storybook with their different states (stories). Chromatic captures a screenshot of each story on every commit, compares it with the baseline, and flags the changes.
It is a perfectly integrated workflow for teams working with design systems. Your designer defines a button with four variants (primary, secondary, disabled, loading). Your developer implements those variants and creates the matching stories. On every code change, Chromatic checks that the four variants have not visually regressed. If the button's border-radius accidentally changes, Chromatic catches it before anyone does a code review.
The tool also offers a UI review feature that lets designers and developers visually approve changes before the merge. It is essentially a visual code review, and it is genuinely useful for keeping a design system consistent.
As of 10/2026, Chromatic is no longer limited to stories: it also runs interaction and accessibility tests, builds on existing Playwright, Cypress, or Vitest tests, and renders captures in four browsers (Chrome, Firefox, Safari, Edge). It also presents itself as a safeguard for interfaces written by AI agents, with a documented MCP server that gives them the context of validated components.
Chromatic's Blind Spot: The Real World
Here is the problem Chromatic does not solve (not through a lack of quality, but by architectural choice): isolated components do not behave like assembled pages.
A button tested in isolation in Storybook is rendered in a controlled environment: a fixed viewport, no neighbors, no inherited CSS context, no dynamic data, no interactions with other components. That is precisely what makes the test reliable at the component level. But it is also what makes it blind to assembly problems.
What breaks visually in production? Rarely an isolated component. What breaks is the combination. A header component that overlaps a navigation component because a z-index changed. A product grid that misaligns because a card component received an extra margin. A form that overflows its container because a label is longer than expected in another language. A footer that climbs over the main content because an intermediate section lost its minimum height.
These bugs are invisible in Storybook. Each component, taken alone, is visually correct. It is their assembly that is the problem. And Chromatic, by design, does not test the assembly: it tests the bricks, not the building.
Delta-QA tests the building. You record a journey on your site, without code, and the tool replays it in a real browser on every version, with all components assembled, with their inherited styles, interactions, and data. Each page is compared with its reference the way a human eye would: the report says which element changed (a button that went from blue to green, a margin that moved). It is the test of reality, not the test of the architect's blueprint.
The Gap Between Storybook and Production
There is a structural gap between what Storybook shows and what production displays, and that gap is rarely discussed.
Data. In Storybook, your components receive mock data, carefully chosen to be representative and to fit the mockup. In production, they receive real data: a 150-character product name nobody planned for, an image with an unlikely aspect ratio, a price with a variable number of decimals, a list of categories that fills three lines instead of one. This real data creates visual situations that Storybook never reproduces.
Inherited styles. In Storybook, each component is rendered in a relatively clean CSS sandbox. In production, components inherit global styles, CSS resets, themes, contextual overrides, and sometimes third-party styles (analytics widgets, chatbots, cookie banners). A component can be perfect in Storybook and visually broken in production because of a style conflict that no story reproduces.
Dynamic states. Storybook tests predefined states, the ones the developer chose to document. In production, components go through intermediate states, unplanned error states, and combinations of states nobody thought to test. The form with a validation in progress, the button in a flex container that resizes, the product card with a promotion that adds a badge: each combination is a visual test that Storybook does not cover.
Delta-QA tests what your users actually see. Not what Storybook promises they will see.
No-Code vs Storybook: The Audience Question
Chromatic is aimed at front-end developers who work with Storybook. That is a legitimate and important audience. But it is a narrow one.
To use Chromatic, you need tests written in code: Storybook stories, or Playwright, Cypress, or Vitest tests. You must know how to write them. You must understand the concept of a baseline and a visual snapshot. You must be comfortable with a workflow based on pull requests and continuous integration. In short: you must be a front-end developer.
Your QA manager who wants to check a page before the release? They cannot use Chromatic directly. Your product owner who notices a visual problem during acceptance testing? They cannot launch a test. Your designer who wants to compare the mockup with the production result? They have no access to the Chromatic workflow without going through a developer.
Delta-QA opens visual testing to the whole team. No Storybook required. No code. No CI/CD pipeline to understand. You browse your site like a user, Delta-QA records the scenario, replays it on the next version, and you read the report. The QA checks the checkout journey before going live. The product owner verifies that a change has not broken anything elsewhere. Everyone is autonomous.
For developers who want their pages checked from their Playwright tests in CI, Delta-QA now has an SDK, the Vision SDK: one line per page to check, and an unreviewed difference makes the test fail.
This is not technological anti-intellectualism. It is the recognition that visual quality concerns everyone, and that tools should reflect that reality.
Components vs Pages: Two Complementary Test Levels
Rather than pitting Chromatic against Delta-QA, it is fairer to position them as two levels of a complete visual testing strategy.
Component level (Chromatic): verify that each brick of the design system visually matches its specifications. It is the unit test of the visual. It detects regressions at the most granular level, as early as possible in the development cycle (even before the merge).
Page level (Delta-QA): verify that assembled pages, with real data and cascading styles, are visually correct. It is the integration test of the visual. It detects assembly problems, style conflicts, and regressions that only exist in the context of the full page.
A team that does both has remarkable visual coverage. Component regressions are caught early by Chromatic. Page regressions are caught by Delta-QA. The safety net is double.
But if you can only pick one (because of budget, time, or resource constraints), the question becomes: which level of testing best protects your users? And the answer, unambiguously, is the page level. Because your users don't see components. They see pages.
Cloud or On-Premise: Where Do Your Captures Go?
Beyond the components/pages model, there is an architectural difference that weighs heavily for some organizations: where your screenshots live.
Chromatic is a cloud service. Your screenshots are sent to and stored on Chromatic's infrastructure; as of 10/2026, its pricing grid does not mention a self-hosted deployment, even on the Enterprise plan (which offers SSO, SLA, and data retention settings). For most public projects, this is not an issue. But for an internal application, a back-office containing customer data, or an organization subject to strict regulatory constraints, the mere fact that interface captures leave the company perimeter can be a blocker.
Delta-QA offers an On-Premise option, installed with Docker on your infrastructure: your captures never leave your network, and the offer can be evaluated through a free one-month POC. It is the same logic as the data sovereignty detailed below, but framed at the architecture level: data stays vs data leaves.
The Business Model: Per-Snapshot Billing
Chromatic bills by the number of snapshots per month. One snapshot = one story, one browser, one resolution. With 200 components at 3 stories each on 2 browsers, that is 1,200 snapshots per build. Twenty builds a day (an active team) comes to 720,000 per month.
As of 10/2026, the free plan offers 5,000 billed snapshots per month, enough to cover a first scope, but quickly used up as the design system grows. And that free plan is limited to Chrome: cross-browser testing (Firefox, Safari, Edge) starts at the Starter plan, at $179/month for 35,000 snapshots. The Pro plan goes up to $399/month for 85,000 snapshots, each extra snapshot is billed $0.008, and Enterprise is quote-based. TurboSnap softens the bill: only the tests affected by a file change are recaptured, and the others count less toward the quota. Concretely, 180 stories × 3 resolutions = 540 snapshots per build, barely 9 builds before the free quota runs out. And this creates the same tension as with Percy: test coverage is inversely proportional to budget. Without TurboSnap, teams end up limiting the stories tested or the build frequency to stay within their quota.
Delta-QA starts with a free account, no credit card. Its coverage is reasoned in terms of journeys and verified steps, not stories multiplied by browsers and resolutions.
Chromatic tests isolated components; what about your full pages? Delta-QA covers them with no-code and no credit card. Try Delta-QA for free →
What Chromatic Does That Delta-QA Doesn't
Transparency requires acknowledging Chromatic's unique strengths.
Collaborative UI review. Chromatic's workflow lets developers and designers visually approve component changes as part of a pull request. It is an integrated review process with no exact equivalent in Delta-QA.
Testing every state of a component. If your button has 12 variants (size, color, state, theme), Chromatic tests them all systematically. Testing those 12 variants at the page level would require finding 12 different pages where they appear, which is not always possible.
Multi-browser. Chromatic captures your tests on Chrome, Firefox, Safari, and Edge (from the Starter plan). Delta-QA currently compares on Chromium; Firefox and WebKit are planned.
Native Storybook integration. Chromatic is made by the creators of Storybook. The integration is as deep as it gets: automatic detection of new stories, minimal configuration, smooth workflow. It is a real advantage if Storybook is the center of your UI development workflow.
Living visual documentation. Chromatic keeps a visual history of each component over time. It is a living design library that shows how each component evolves, a valuable feature for design systems.
What Delta-QA Brings That Chromatic Doesn't Cover
The test of reality. Production pages, with real data, real inherited styles, and real interactions between components. Not Storybook's clean idealization, but the world as it is.
Universal accessibility. Any team member can run a visual test. No need to be a developer, no need to know Storybook, no need for access to the CI pipeline. The democratization of visual testing.
Technological independence. Delta-QA works whatever your front-end stack. React, Vue, Angular, Svelte, WordPress, Shopify, a static site, a legacy jQuery application, it doesn't matter. If it displays in a browser, Delta-QA tests it. Chromatic relies on tests written in code (Storybook, Playwright, Cypress, Vitest), and therefore on a front-end project equipped for it.
Data sovereignty. With the On-Premise offer, the comparison runs on your infrastructure and no capture is sent to a third party. For internal applications, sensitive data, and organizations subject to strict regulations.
A report that names the elements. Each difference is tied to an element of the page and described in plain language: the color, the margin, the font, the position. You know what to look at without interpreting a diff image.
The Ideal Scenario: Both Together
If your team already uses Storybook and has the budget for Chromatic, combining the two tools is the most robust strategy.
Chromatic watches your components at the design system level. Every style change, every variation, every state is visually verified. Regressions are caught at development time, before the code reaches the main branch.
Delta-QA watches your pages in production (or staging). Assembly problems, style conflicts, and bugs that only appear in the real context are caught before users see them.
Together, they give double coverage: the bricks on one side, the assembled journeys on the other.
The Pragmatic Scenario: A Single Tool
If you have to choose a single tool (because the budget is limited, the team is small, or you want to start simple), the question boils down to this: what best protects your users?
Your users don't see your Storybook components. They see your pages. They interact with your pages. They form their opinion of your product by looking at your pages. A component that is perfect in Storybook but broken in the assembled page is a broken component from the user's point of view.
Delta-QA tests what your users see. It's as simple as that.
Ready to test the pages your users really see? Launch your first comparison with Delta-QA, with a free account and no credit card. Try Delta-QA for free →
FAQ
Does Chromatic work without Storybook?
Yes. As of 10/2026, Chromatic also captures the pages of your Playwright, Cypress, or Vitest tests, in addition to Storybook stories. You do need tests written in code, though: they define what gets captured. Delta-QA starts from a scenario recorded without code, whatever the stack that produces your pages; for Playwright tests, it offers its Vision SDK.
Is testing components in Storybook enough to guarantee visual quality?
No. Components tested in isolation do not reproduce the real conditions of an assembled page: style inheritance, dynamic data, interactions between components, third-party styles. Chromatic checks that your bricks are correct. Delta-QA checks that the assembly is correct. Both levels are needed for complete coverage.
Does Chromatic detect responsive issues?
Yes, within the limits of what Storybook shows. You can configure your stories for different viewport sizes, and Chromatic will test them. But responsive issues specific to an assembled page (an element that overflows when combined with others, a layout that breaks with long real data) will not be detected. Delta-QA, for its part, compares the assembled page in a real browser, with its real data.
What does Chromatic's free plan cover?
As of 10/2026, Chromatic's free plan offers 5,000 billed snapshots per month, on Chrome only, which covers a few dozen components with occasional builds. As soon as the number of components or the build frequency grows, the quota is quickly reached. A project with 100 components, 3 stories per component, and 2 daily builds consumes about 18,000 snapshots per month without TurboSnap.
Can Delta-QA be used to test isolated components?
Delta-QA is optimized for full pages, not isolated components. If you have an environment where your components are rendered individually on accessible URLs (like a deployed Storybook), you can technically use Delta-QA to compare them. But that is not its main use case. For testing isolated components, Chromatic remains the reference tool.
How does Delta-QA handle design systems if not at the component level?
Delta-QA checks the visual consistency of your design system at the level where it matters most: in the pages that use it. If a change in your design system breaks the layout of a dozen pages, Delta-QA detects it directly. It is an end-to-end test of the design system, complementary to Chromatic's unit-level test.