Storybook Visual Testing Without Chromatic: Testing Your Components Without Vendor Lock-In
Visual testing is an automated verification method that compares screenshots of an interface — or an isolated component — against reference images to detect any unintended visual regression.
If you use Storybook, you've probably heard of Chromatic. It's the visual testing tool built by the Storybook team itself, so deeply integrated into the ecosystem that you might think it's the only option available. It's not. And believing otherwise is a trap too many teams fall into.
This article explores why relying on a single vendor for visual testing your Storybook components is a risky strategy, what alternatives actually exist, and how to choose the approach that fits your context.
Why Storybook and Visual Testing Go Hand in Hand
Storybook has transformed the way front-end teams build and document their components. Each component lives in isolation, with its variants, states, and edge cases. It's a living catalog of your design system.
But a catalog without automated verification is a museum no one's watching. One developer changes a color token in the global theme. Another adjusts a padding to fix a bug on a page. A third updates a CSS dependency. None of these changes break a unit test. None of them fail an integration test. But visually, three components are now broken.
Visual testing fills that gap. It captures the actual appearance of each component in Storybook and detects deviations from an approved reference. It's the safety net your functional tests don't provide.
Chromatic: What It Does Well, and the Problem
Let's be honest: Chromatic is a good product. The Storybook integration is seamless — makes sense, since it's the same team. The review workflow is well designed. Change detection is smart.
So, what's the problem?
Vendor lock-in is real
When your entire visual testing pipeline relies on a single cloud service, you're handing it considerable power over your delivery workflow. If Chromatic changes its pricing — which happens regularly in SaaS — you don't have a plan B ready to deploy. If the service goes down, your merge requests wait. If the API evolves and breaks your integration, your CI grinds to a halt.
This isn't paranoia. It's basic risk management.
Snapshot-based pricing is a ticking time bomb
Chromatic charges per snapshot. Early on, with 50 components and 3 variants each, the bill is reasonable. But a design system grows. Variants multiply. Themes get added. A year later, you have 400 stories and the bill has multiplied eightfold. At that point, reducing the number of snapshots means reducing test coverage — exactly the opposite of what you want.
Your test data leaves your infrastructure
For teams subject to compliance constraints (healthcare, finance, government), sending interface screenshots to a third-party cloud service isn't trivial. Even if screenshots don't theoretically contain sensitive data, security policies don't always make that distinction.
Alternatives to Chromatic for Storybook Visual Testing
Percy (BrowserStack)
Percy is the most established direct competitor. Its approach: you capture snapshots of your Storybook stories, Percy renders them in real browsers in the cloud, and you review differences in a dashboard.
What works. Percy handles cross-browser natively. You test your components in Chrome, Firefox, Safari without configuring anything locally. The review dashboard is mature and the approval workflow is solid.
What's problematic. You're leaving one cloud vendor for another. Pricing is also snapshot-based. And the Storybook integration, while functional, isn't as native as Chromatic's — understandably, Percy wasn't designed specifically for Storybook.
Percy makes sense if your primary need is cross-browser visual testing and you're comfortable with a paid cloud model. But it doesn't solve the fundamental vendor dependency problem.
Playwright with toHaveScreenshot()
Playwright natively includes screenshot comparison. With some configuration, you can use it to visually capture and compare your Storybook stories.
What works. Everything runs locally or in your own CI. No third-party cloud service. No per-snapshot billing. Baselines live in your repo, under your full control. And Playwright is maintained by Microsoft — longevity isn't a concern.
What's problematic. Setup takes work. You need to write the logic that opens each story in a headless browser, takes a screenshot, and compares it. For the exact technical configuration, ask your favorite AI copilot — it'll happily generate a Playwright/Storybook script while you grab a coffee. But you'll be maintaining that code. False positives from pixel-by-pixel comparison will require tuning. And you don't get a review dashboard: when a test fails, you're opening PNG files locally to figure out what changed.
Playwright is the solid technical choice for teams with in-house expertise who want zero external dependencies. But it's a maintenance investment.
BackstopJS
BackstopJS is an open-source tool dedicated to visual regression. It can target URLs — including your locally served Storybook stories.
What works. It's free, open source, and the generated HTML report is more readable than a folder of diff files. The JSON scenario configuration is straightforward.
What's problematic. The project has gone through periods of intermittent maintenance. The Storybook integration isn't direct — you need to point BackstopJS at the individual URLs of each story. For a precise configuration, your favorite AI assistant — the one that secretly dreams of becoming a front-end developer — will whip up the config in no time. But at the scale of a substantial design system, scenario management becomes verbose.
Delta-QA: The No-Code Approach
Delta-QA takes a different angle. No scripts to write. No SDK to integrate into your tests. You point the tool at your served Storybook stories (locally or in CI), and Delta-QA handles capturing, comparing, and presenting differences in a dedicated review interface.
What changes. Visual testing of your Storybook components no longer depends on your test stack. Your QA team can configure and maintain visual coverage without touching test code. Designers can participate in the review workflow — they see visual differences without needing to understand a test report.
What's different from Chromatic. Delta-QA runs wherever you decide. No per-snapshot billing. No dependency on a cloud service you don't control. Your captures stay in your infrastructure.
How to Choose: The Decision Grid
Rather than pretending one solution fits all — that would be dishonest — here are the questions to ask yourself.
Do you have data sovereignty constraints? If yes, eliminate Chromatic and Percy. That leaves Playwright, BackstopJS, and Delta-QA.
Does your team have the skills to maintain visual test scripts? If not, eliminate Playwright and BackstopJS. Delta-QA's no-code approach or Chromatic/Percy's managed model are better suited.
Is your design system actively growing? If yes, watch out for per-snapshot pricing. What costs $50 per month today could cost $500 in a year.
How many browsers do you need to cover? If cross-browser is critical, Percy has a native advantage. For others, headless Chrome is often enough to catch visual regressions.
Do you want to involve non-developers in reviews? If your designers or QA team need to validate visual changes, a tool with an accessible review interface (Delta-QA, Chromatic, Percy) will be preferable to a folder of PNG files in Git.
The Hidden Risk: Tooling Monoculture
Beyond tool selection, there's a more fundamental principle that many teams overlook: don't put all your tests in one vendor basket.
If your CI, functional tests, visual tests, and monitoring all depend on a single ecosystem, a single business decision from that vendor can paralyze your entire pipeline. That's true for Chromatic, and it's true for any tool.
Resilience in software engineering comes through diversification. You don't host your database and application on the same physical machine. Apply the same logic to your testing toolchain.
Migrating from Chromatic: Where to Start
If you're currently on Chromatic and considering an alternative, don't do a big bang. Take it step by step.
Step 1: Identify your critical stories. Not all of them. The 20% that cover 80% of the components visible to your users.
Step 2: Set up the alternative in parallel. Run Delta-QA (or Playwright, or the tool of your choice) on those critical stories alongside Chromatic. Compare results over two to three sprints.
Step 3: Expand gradually. Once confidence is established, extend coverage and reduce your Chromatic usage proportionally.
Step 4: Cut the cord. When alternative coverage reaches a satisfactory level, deactivate Chromatic.
This approach takes time. But it avoids the nightmare scenario where you discover the limitations of your new tool in production.
FAQ
Is Storybook visual testing really necessary if we have unit tests?
Yes. Unit tests verify that your component works — that it accepts the right props, renders the correct content, and responds to events. Visual testing verifies that it looks the way it should. A component can pass all its unit tests and have a completely broken layout. These are two complementary dimensions.
Can you use Playwright to visually test Storybook without Chromatic?
Absolutely. Playwright can navigate to each story individually and compare screenshots. The effort lies in setup and maintenance: you need to write the code that iterates over your stories, manage baselines, and handle false positives. It's doable but it's an engineering time investment.
Does Delta-QA work with Storybook directly?
Yes. Delta-QA can target any served URL, including individual Storybook stories. You don't need to modify your Storybook configuration or install a plugin. As long as Storybook is accessible (locally or via a CI deployment), Delta-QA can capture and compare your components.
Is pixel-by-pixel comparison reliable for Storybook components?
It's reliable if your rendering environment is perfectly stable — same OS, same browser, same resolution, same fonts. In practice, achieving that stability between a developer's machine and a CI runner takes work. Perceptual approaches (which tolerate minor rendering differences) or tools that manage this stability for you significantly reduce false positives.
How much does Storybook visual testing cost if you leave Chromatic?
It depends on the alternative. Playwright and BackstopJS are free (open source) but cost engineering time. Percy charges per snapshot like Chromatic. Delta-QA offers a different model that doesn't penalize you for design system growth. Do the math with your actual number of stories and variants.
Is it possible to combine multiple visual testing tools on the same project?
Not only is it possible, but it's sometimes recommended. You could use Playwright for critical visual tests in your CI pipeline and Delta-QA for collaborative review with your design team. Diversification reduces your dependency risk and lets you leverage each tool's strengths.
Conclusion
Storybook visual testing is essential for any team maintaining a serious design system. But the tool you choose to do it has implications far beyond the technical. It affects your budget, your autonomy, and the resilience of your delivery pipeline.
Chromatic is a good tool. It's not the only one. And in a context where flexibility and independence are strategic advantages, exploring alternatives isn't a luxury — it's prudence.
If you're looking for a no-code approach, without vendor lock-in, that works with Storybook as well as any web application, Delta-QA deserves your attention.