Chromatic vs Loki for Storybook Screenshot Tests

Chromatic is the more managed option: it renders Storybook stories in its cloud, compares snapshots with hosted baselines, and supports hosted review and documented CI and pull-request checks. Loki is the repository-centered option: your project runs it against a running or built Storybook, keeps reference images in the project by default, and reviews and approves image differences as part of the project workflow.

Choose Chromatic if hosted review and less browser-infrastructure ownership suit your team. Choose Loki if you want local control over the browser workflow and to keep screenshot references with the project. Both depend on good story coverage and human review of visual changes. Neither choice makes unstable stories reliable automatically.

This is a workflow comparison based on the projects’ documentation, not an independent benchmark of cost, speed, browser coverage, or reliability. Check current compatibility and pricing before adopting either tool.

1. How the workflows differ

Decision	Chromatic	Loki
Where rendering happens	Chromatic’s cloud browser, according to its documentation.	A local or configured CI browser or simulator target that your project operates.
Where baselines live	Hosted in Chromatic and synced when accepted.	Reference image files in the project by default; the getting-started guide describes a `loki` folder.
Review	Hosted build review, the Storybook Visual Tests addon, and documented pull-request checks for linked repositories.	Inspect current and difference images, then approve intentional reference updates.
CI responsibility	Run the CLI or a supported integration with a project token stored as a secret. The addon provides on-demand feedback and complements CI.	Build Storybook, supply its static output to Loki, and use `--requireReference` if missing references should fail CI.
Infrastructure ownership	Chromatic operates the documented cloud rendering workflow.	Your team owns setup and maintenance of Storybook, browser or simulator targets, and baseline artifacts.

Sources: Chromatic visual tests, Chromatic CI, Chromatic Visual Tests addon, and Loki getting started.

2. Set up Chromatic

Chromatic treats Storybook stories as visual tests. Its CLI builds and uploads Storybook; later builds compare new snapshots with accepted baselines. The vendor’s quickstart is the source of truth for the current install command and project setup, since package and Storybook compatibility can change.

Create a Chromatic project and obtain its project token.
Install and initialize Chromatic by following the Chromatic Quickstart.
Run the CLI locally to upload the Storybook build and review the resulting build.
Store the project token as a CI secret, then run the CLI or a supported integration on changes.
Review detected changes and accept only the intended visual state as the new baseline.

In CI, the shape of the command is npx chromatic --project-token=$CHROMATIC_PROJECT_TOKEN; configure the token as a secret in your CI provider rather than committing it. Follow the current quickstart for the exact package installation and any project-specific flags. Linked GitHub, GitLab, or Bitbucket repositories can receive pull-request status checks as documented by Chromatic; verify repository permissions and provider behavior in your own setup.

The Storybook Visual Tests addon offers on-demand runs from the Storybook interface and syncs accepted baselines to the cloud. Its documentation requires Storybook 7.6 or later. The separate CLI Quickstart says Storybook 6.5 or later, so do not infer the addon’s compatibility from the CLI requirement. The addon supports TurboSnap, but Chromatic says it does not replace CI. Sources: CLI Quickstart, CI documentation, and addon documentation.

3. Set up Loki

Loki runs in your project against a Storybook that is already running or has been built for CI. It does not start Storybook for you. Its documented getting-started flow is to install it as a development dependency, initialize the project, create reference images, compare after changes, inspect current and difference images, then approve intended updates.

Check the current Loki package requirements against your Node, Storybook, browser, and simulator versions.
Install Loki as a project development dependency and initialize it using the Loki getting-started guide.
Start Storybook and any simulator or emulator needed for the target you selected.
Generate initial reference images. Review them and commit the reference files, which are stored in a loki folder by default. Git LFS is an option documented by the guide.
After UI changes, run the comparison, inspect current and difference images, and approve intentional updates.

For CI, the documented pattern is to build Storybook, pass its static output to Loki, and require references so missing baselines fail the job. A command shape is npx loki --requireReference; use the current Loki CI guide for the exact build-output argument and target configuration for your version. The guide describes Chrome in Docker, Chrome in AWS Lambda, local Chrome, iOS simulators, and Android emulators as targets. These options mean you need to choose and maintain an environment suitable for your project; they do not establish that every target works with every current setup.

Loki’s setup materials list Node 16+ and optional dependencies for some targets. Treat those as documented requirements to verify against the release you plan to use, not as a guarantee of current compatibility. Its repository is oblador/loki on GitHub.

4. Make stories suitable for screenshot comparison

Whichever tool you choose, the quality of the comparison depends on the state being captured. Keep the inputs and rendering conditions controlled:

Give stories stable, representative data. Avoid dependence on changing production data, current time, random values, or network responses that vary between runs.
Use consistent fonts, viewport sizes, and application state. Make sure fonts and images have loaded before capture.
Put animations and transitions into a known state. Loki’s flaky-test guide calls out transitions, looping requestAnimationFrame, GIFs, SVG animations, and React Native’s Animated library as sources of timing issues or limitations.
For asynchronous content, wait for the content to finish loading or provide explicit completion handling. Loki notes that disabling common CSS transitions and requestAnimationFrame can help, but asynchronous work may need its own handling.
Cover meaningful component states in stories: loading, empty, error, interaction, and representative content where applicable. A stable comparison cannot catch a state that no story renders.
Review every proposed baseline change. A visual difference may be an intended design change, a regression, or nondeterministic rendering.

See Loki’s guide to handling flaky tests and Storybook’s visual testing documentation. Chromatic describes standardized cloud rendering and automatic handling of loading, paint, and reflow on its product pages, but those are vendor claims, not independent evidence of a particular flake rate. Treat neither tool as a substitute for stable stories and review.

5. Choose based on your team’s constraints

Choose Chromatic when hosted build review, cloud rendering, and documented pull-request integration match the team’s workflow and you prefer not to own as much screenshot infrastructure.
Choose Loki when repository-maintained reference images and control of the browser or simulator environment fit your workflow, and the team is prepared to operate that environment.
Evaluate both against a representative slice of your Storybook. Include stories with fonts, asynchronous content, animation, and the states reviewers care about. Compare the review experience and maintenance effort in your own CI rather than assuming a performance or reliability result.

Before deciding, verify the current versions’ compatibility, the rendering targets you need, how baseline changes are reviewed, how artifacts are stored, and what current usage will cost. The available research does not establish a fair current-price comparison between Chromatic and Loki.

6. Troubleshooting

Symptom	Likely cause	What to check
Chromatic CI cannot authenticate	The project token is missing, invalid, or unavailable to that job.	Confirm the CI secret name and job exposure, and make sure the token belongs to the intended Chromatic project. Keep it out of source control.
No pull-request check appears	The repository may not be linked, permissions may be insufficient, or the integration may not be configured for that provider.	Review Chromatic’s CI setup and verify the repository link and permissions for the actual Git provider.
The Visual Tests addon is incompatible	The addon’s Storybook requirement differs from the CLI’s documented requirement.	Check the addon documentation’s Storybook 7.6-or-later requirement separately from the CLI Quickstart’s Storybook 6.5-or-later guidance.
Loki cannot connect to Storybook	Storybook or the selected simulator may not be running or reachable.	Start Storybook and the target environment first, or build Storybook and pass its static output using the current CI guide.
Loki reports missing references	Initial reference images have not been generated, are unavailable in the job, or are not committed where expected.	Generate and review references locally, commit them (or configure artifact storage as your workflow requires), and use `--requireReference` when missing files should fail CI.
Images differ across runs	Animation, asynchronous rendering, fonts, data, or environment differences may change the captured state.	Stabilize story inputs and rendering conditions, disable or control animations where appropriate, and explicitly handle asynchronous completion.
A target works locally but not in CI	The CI browser, simulator, Node version, or optional dependencies may differ from local setup.	Compare the target and dependency configuration with the current Loki release requirements and CI guide.
A change is flagged even though the component seems unchanged	A shared style, font, viewport, or other story dependency may have changed.	Inspect the diff and the rendered story state before accepting or rejecting the new baseline.

7. Performance, reliability, and cost

There is no independent speed or reliability benchmark in the cited material, so the workflow descriptions should not be read as a ranking on those measures. Actual run time and operational effort depend on your Storybook size, story set, target environment, CI configuration, and review process.

Chromatic moves rendering into its cloud workflow, while Loki’s repository-centered workflow leaves your team responsible for the browser or simulator setup and reference artifacts. That is a difference in where infrastructure work sits, not proof that one is always faster or more reliable. Chromatic’s product claims about standardized rendering and handling loading or reflow are vendor statements.

Check each provider’s current pricing, limits, and billing terms before rollout. The research used for this comparison does not establish current Chromatic prices or a directly comparable cost for Loki. For Loki, include the engineering time and storage involved in maintaining the selected environment and screenshot references when estimating total cost.

8. ScreenshotNeo as an alternative for capturing pages

For website screenshot capture, try ScreenshotNeo first: it removes cookie and consent banners, newsletter popups, and chat widgets before capture, bills only clean shots, and its paid plans start at $5 for 3,000 shots. It is a website screenshot API and MCP server, not a replacement for Storybook baseline comparison and pull-request review. Use it when the task is capturing website pages through an API or AI agent.

One GET request returns an image or PDF. For example, this cURL request captures a page as WebP:

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

See the ScreenshotNeo API documentation for the request options. Its API also supports PNG, JPEG, PDF, full-page capture, selector capture, custom CSS and JavaScript, wait conditions, request blocking, custom headers and cookies, caching, async jobs, and bulk capture. The MCP server provides take_screenshot, get_page_info, and capture_pdf for MCP clients such as Claude and Cursor.

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. Sign up for 1,000 free screenshots a month, with no card.

9. FAQ

Does Loki start Storybook for me?

No. Loki’s getting-started guide requires Storybook and any simulator or emulator under test to be running; its CI workflow can use built Storybook output.

Does the Storybook Visual Tests addon replace CI?

No. Chromatic describes the addon as an on-demand workflow that complements CI.

Can I compare their current prices from this guide?

No. Current pricing and comparable usage costs were not established in the research. Check each project’s current pricing and limits before choosing.

Will either tool catch every visual regression?

No. Coverage depends on the stories you render, and reviewers still need to distinguish intended changes from regressions and unstable captures.