Visual regression: an unintended change in the appearance of a user interface (layout, colors, typography, spacing, alignment), introduced by a code change, a dependency update, or a configuration change, and detectable only by automated comparison between two states of the interface.
Lost Pixel carved out an interesting place in the visual testing ecosystem. Open source, specialized in Storybook and Ladle components, integrable into CI pipelines: it was a tool that spoke directly to front-end developers living in the component universe.
Update (10/2026). On April 22, 2026, Lost Pixel's founders announced the end of the product: the team is joining Figma. The GitHub repository is archived, and the latest version published on npm (3.22.0) dates from November 2024. The code remains available under the MIT license, but it will no longer evolve. This comparison keeps its description of the tool, useful if you still use it, and helps you choose what comes next.
But here is the question nobody asks early enough in the evaluation: is your need to test isolated components in Storybook, or to verify that your site works visually under real conditions?
The answer to that question determines what to migrate to: another component-centered tool, or an approach that tests your real pages like Delta-QA. And that answer depends less on technology than on the makeup of your team and the nature of your visual quality problems.
All our comparisons, based on verifiable criteria: Alternatives and comparisons.
Detect visual regressions without touching npm or a config file. Delta-QA is used no-code, with a free account and no credit card. Try Delta-QA for free →
Lost Pixel: The Component Specialist
Lost Pixel is an open source visual regression testing tool, now archived. Its favorite ground: Storybook, Ladle, Histoire (UI component development environments) and static web pages. The tool captures screenshots of your components or pages and compares them between runs to detect visual changes.
Storybook Integration as a Strength
If you develop with Storybook (and in 2026, a majority of React, Vue, or Angular front-end teams do), Lost Pixel plugs directly into your catalog of stories. Each story automatically becomes a visual test. No need to manually list the pages to test or to write navigation scenarios: your Storybook catalog is your visual test suite.
It's a clear value proposition, immediately understandable to a front-end developer. You already maintain your stories for documentation and component development. Lost Pixel turns them into visual regression tests with no extra effort.
The tool also supports Ladle (the lightweight alternative to Storybook) and Histoire (for Vue), which covers most of the component development ecosystem. And beyond components, Lost Pixel can test full web pages in "page shots" mode.
A Tool Designed by and for Developers
Lost Pixel is installed via npm, configured in a TypeScript or JavaScript configuration file, and run from the command line. CI integration is documented for GitHub Actions, and the Lost Pixel platform (cloud version) added a review and baseline approval workflow; with the announced shutdown, don't count on it for a new project.
The learning curve is reasonable for a developer. If you know npm, configuration files, and GitHub Actions, you can be operational in under an hour. It's simpler than Applitools or Percy: Lost Pixel doesn't drown you in options and integrations.
But this simplicity for developers is a barrier for everyone else. If you are not a developer, installing an npm package, writing a configuration file, and configuring a GitHub Action is about as accessible as piloting a submarine without training.
Pixel-to-Pixel Comparison
Lost Pixel compares screenshots: images captured from your components or pages. It's the most intuitive and widespread approach in visual testing. You literally see what changed, overlaid on an image.
This approach has an undeniable merit: it's visual. The report shows you the differences graphically. You don't need to understand CSS to see that a button moved or a color changed.
But it also has a structural weakness: sensitivity to rendering noise. Anti-aliasing variations between two renders, font differences between the local environment and CI, unsynchronized animations: all of this generates false positives. Lost Pixel offers a configurable tolerance threshold, but calibrating that threshold correctly is a delicate art: too sensitive and you drown in false positives, too tolerant and real regressions go unnoticed.
Delta-QA: Visual Testing for the Whole Team
Delta-QA starts from a simple observation: visual testing shouldn't be reserved for developers. The people best qualified to judge the visual quality of an interface (designers, functional QA, product owners) are often excluded from the process because existing tools require technical skills.
Developers aren't excluded either: those who write their tests in Playwright now have the Vision SDK, one line per page to check, in the same space as the scenarios recorded without code.
The No-Code Approach
With Delta-QA, you create a free account. You enter your site's URL. You browse normally, as a user would. Each step of the journey becomes a checkpoint. On the next run, Delta-QA replays the journey in a real browser, compares each page with its reference, and shows you what changed.
No npm. No configuration file. No command line. No GitHub Actions. If you know how to use a web browser, you know how to use Delta-QA.
This accessibility is not a compromise on the tool's power: it's a design choice that considerably widens the range of people able to contribute to visual quality. A designer can verify that their specifications are respected. A functional QA tester can build visual testing into their validation routine. A product owner can make sure a deployment broke nothing visually before giving the green light.
Element Comparison Instead of Pixels
Where Lost Pixel compares images pixel by pixel, Delta-QA compares the elements of the page and reports the change in plain language. It's a fundamental difference that changes the nature of the results.
When Delta-QA flags a change, it doesn't show you a colored rectangle on an image. It tells you exactly what happened: "the title's font-size went from 24px to 20px", "the header's background color changed from #FFFFFF to #F8FAFC", "the button's padding decreased from 16px to 12px".
This information is directly actionable. You know what to fix, which CSS rule to look in, and how to verify that the fix is effective. With an image comparison, you know that something changed visually: finding out exactly what requires manual investigation.
This approach also limits false positives. An anti-aliasing or sub-pixel variation changes neither the color, nor the size, nor the position of an element: there's no reason for it to be flagged. What remains to be judged are the changes that actually affect the page.
The On-Premise Option
For organizations that require it, Delta-QA offers an On-Premise offer installed with Docker on your infrastructure: no data leaves your network, no screenshots are sent to a remote server.
SaaS remains the fastest entry point: free account, no credit card. The On-Premise offer can be evaluated through a free one-month POC.
The Central Debate: Isolated Components vs Real Pages
The choice between Lost Pixel and Delta-QA hides a deeper debate about what "visually testing" an application really means.
The Component Approach: Necessary but Insufficient
Lost Pixel, through its Storybook integration, tests isolated components. Each component is rendered individually, in a controlled environment, with defined props. It's excellent for detecting regressions at the component level: a button whose border-radius changed, a text field whose placeholder disappeared, a badge whose color became inconsistent.
But the most impactful visual bugs don't happen at the level of the isolated component. They happen when components come together in a real page. A navigation component that pushes the content down by 50 pixels. A footer that overlaps the main content on mobile. A card grid that breaks when a text is longer than expected. A modal that no longer centers correctly when the window is resized.
These visual integration problems are invisible in Storybook, because Storybook doesn't show integration: it shows individual bricks. It's like testing each gear of a watch separately and concluding the watch works. The gears can be perfect individually and not mesh properly once assembled.
The Page Approach: The User's Reality
Delta-QA tests real pages, in a real browser, with your application's real HTML, CSS, JavaScript, and interactions. When Delta-QA tells you your page is visually correct, it's because it is, under the conditions in which your users will see it.
It's not an abstraction, not an isolated environment, not a partial render. It's your page, as a whole, with all the interactions between components, all the inherited styles, all the CSS overrides, all the cascade effects.
This approach catches the visual integration bugs that isolated component tests structurally miss. It also catches problems tied to real data: a 40-character name that overflows a field, a 5-digit price that breaks a layout, a missing image that collapses a page layout.
Open source for Storybook is powerful but needs configuring. Delta-QA detects your visual regressions without a line of configuration: free account, no-code, and no credit card. Try Delta-QA for free →
What Lost Pixel Did Well
Its strengths explain why teams adopted it, and what you will need to find elsewhere.
Native Storybook integration. If you maintain a Storybook catalog, Lost Pixel turns it into a visual test suite effortlessly. Each story becomes a test. It's an exceptional value proposition for component-centered teams.
CI/CD automation. Lost Pixel integrates naturally into a GitHub Actions pipeline. Visual tests trigger automatically on every pull request, with no human intervention. Coverage is continuous and systematic.
Cost. Lost Pixel is open source and the self-hosted version was free. The cloud platform was paid, at affordable rates; it is affected by the announced shutdown.
Component granularity. Testing each component individually lets you locate regressions at the finest level. When a component changes, you know immediately which one, without having to search through a full page. It's an efficient workflow for developers who work component by component.
Open source. The code remains readable and reusable under the MIT license. But an archived repository no longer receives fixes: with every update of Storybook, Playwright, or Node.js, it's up to you to ensure compatibility.
What Delta-QA Adds
Total accessibility. No technical prerequisites. No npm, no CLI, no configuration file, no GitHub Actions. If you know how to browse a site, you know how to use Delta-QA.
Quality of results. Each difference is tied to an element of the page and described in plain language. You know what changed: not just "something changed visually in this rectangle".
Integration coverage. Delta-QA tests full pages, not isolated components. It catches the visual integration bugs that component tests miss by design: layout problems, style conflicts, the effects of real data on the layout.
Data sovereignty. With the On-Premise installation, no data leaves your network: no third-party cloud service, no external transfer. For companies subject to GDPR or strict security policies, it's a structural advantage.
Time to get started. From account creation to the first recorded journey, count a few minutes with Delta-QA. With Lost Pixel, you had to install the package, write the configuration, have a working Storybook, set up CI: more like one to two hours for an experienced developer.
Involvement of the whole team. No-code visual testing with Delta-QA is a collaborative activity. Designers, QA, product owners, and developers can all take part, read the results, and approve or reject changes.
The Typical Case: Why Components Alone Aren't Enough
Let's take a scenario every front-end team has lived through. You have a design system with a Card component used everywhere on your site. Each Card has a title, an image, a description, and a button. In Storybook, the component is perfect: visually tested, all variants covered.
One day, a developer modifies the site's global CSS. They change the global line-height variable to improve readability. The tests on the Storybook components pass: the global line-height doesn't affect the isolated stories, which have their own context. In production, the catalog page that shows 12 Cards in a grid is completely broken: the taller text pushes the buttons, the Cards no longer have the same height, the grid is visually inconsistent.
This bug is invisible in Storybook, and therefore in a tool that only tests stories. It is visible in Delta-QA, because Delta-QA tests the real page with the global CSS applied.
This is not an extreme or artificial case. It's the daily reality of front-end development: components live in an ecosystem, and their visual behavior depends on that ecosystem. Testing components in isolation is necessary, but it's a necessary condition, not a sufficient one.
The Verdict: What to Replace Lost Pixel With
If your need is centered on Storybook, look for a maintained component tool: Chromatic, published by the Storybook team, is the most direct example (see our Chromatic and Delta-QA comparison and our ideas for Storybook visual testing without Chromatic). Lost Pixel remains runnable as is, but without fixes.
Choose Delta-QA if your team includes non-technical profiles who must take part in visual testing. If you need to test full pages and journeys, not just isolated components. If you want readable results tied to the page's elements. If data sovereignty is a criterion, with the On-Premise offer. If you want to be operational in minutes, not hours.
Combine both levels if you want complete coverage: a component tool in the CI pipeline to watch the basic bricks, and Delta-QA to test full pages, involve non-technical profiles, and verify visual integration before every release.
Ready to test your real pages without configuring anything? Launch your first comparison with Delta-QA, with a free account and no credit card. Try Delta-QA for free →
Frequently Asked Questions
Is Lost Pixel still maintained?
No. On April 22, 2026, its founders announced the end of the product and their move to Figma. The GitHub repository is archived and the latest npm version (3.22.0) dates from November 2024. The code remains usable under the MIT license, but without fixes or evolutions: plan a migration.
Can Delta-QA test Storybook components like Lost Pixel?
Delta-QA tests full web pages, not isolated components in Storybook. If you access your Storybook through a browser, you can technically test your stories with Delta-QA, but it's not its main use. Delta-QA's strength is testing the real integration of your components in full pages: exactly what Lost Pixel doesn't cover.
Does Delta-QA detect the same problems as Lost Pixel's pixel comparison?
Delta-QA detects visible changes in elements: colors, sizes, margins, fonts, positions, borders, giving you the detail of each change. However, changes inside a modified image or a different text content are detected differently by the two approaches.
Do you need Storybook to use Lost Pixel?
No, Lost Pixel could also test full web pages in "page shots" mode. But its Storybook integration was its main value proposition. For page testing, other maintained tools, including Delta-QA, take over.
Which tool is the fastest to set up?
Delta-QA. Create the account, open your site, browse: your first journey is recorded in a few minutes. Lost Pixel required npm, a configuration file, a working Storybook (or page mode), and ideally a configured CI pipeline: one to two hours for an experienced developer.
How do I switch from Lost Pixel to Delta-QA?
Lost Pixel's baselines are images specific to its pixel logic: they can't be transferred. You record your main journeys in Delta-QA, which creates its own references on the first run. For your developers' Playwright tests, the Vision SDK adds a Delta-QA check in one line per page.