Loki vs Percy for Visual Regression Testing

Short answer: Choose Loki if you want an open-source, Storybook-focused workflow and are prepared to run the browser or simulator environment, manage reference images, and review diffs in your own setup. Choose Percy if you want a hosted snapshot, baseline comparison, and team review workflow with documented CI and source-control integrations. The right choice depends on where you want rendering and review to happen, which platforms you need, and what your team wants to maintain.

The available product documentation describes workflows, not an independent head-to-head test. It does not establish that either tool is more accurate, faster, or cheaper overall. Treat those as questions to evaluate against your own application and usage.

What visual regression testing does

Visual regression testing captures a page or component and compares it with an approved reference. A difference can reveal an unintended layout, style, font, or rendering change. A reviewer decides whether the change is expected and should become the new reference, or whether the code needs a fix.

For Storybook teams, the practical choice is often about the workflow around the comparison: who starts and maintains the rendering environment, where references live, how reviewers approve changes, and which browsers or devices need coverage.

Loki and Percy at a glance

Decision area	Loki	Percy
Operating model	Open-source Storybook visual regression project run in your development or CI environment.	Hosted visual testing and review service from BrowserStack.
Capture and comparison	Run the CLI to capture or test references; inspect local diff output and approve changed references.	Capture snapshots in a Percy build, compare against approved baselines, and review changes in the service.
Environment responsibility	Your workflow starts Storybook and any simulator or emulator. The Loki README says Loki does not start these environments itself.	Percy offers managed rendering; BrowserStack documents an Automate configuration path when specific OS and browser versions are needed.
Documented rendering targets	Chrome in Docker (recommended by the repository), Chrome in AWS Lambda, local Chrome, iOS simulator, and Android emulator.	Cross-browser rendering with configurable browser selection; specific OS/browser configurations are documented through Automate.
Team review	Your team reviews diffs and manages its approval process around the CLI and reference files.	Builds and snapshots have a hosted review and approval workflow.
Usage considerations	Plan for environment dependencies, reference storage, and CI integration.	Each browser snapshot counts separately toward monthly screenshot usage. Plan limits and history terms should be checked in current documentation.

These are documented workflow distinctions, not a quality ranking. The Loki repository lists Node 16+ as a prerequisite and describes GraphicsMagick, Docker, and Chrome as optional dependencies for particular modes. Dependencies and compatibility can change, so check the project documentation for the version you plan to install.

How Loki’s workflow works

Loki is explicitly designed for Storybook. Its documented workflow assumes Storybook is running and then uses Loki to capture reference files, compare a later run, inspect the differences, and approve intended updates.

Start Storybook. Loki does not launch it for you. Start it in the environment your test will use.
Choose and prepare a rendering target. The repository documents Chrome in Docker as the recommended target and also lists AWS Lambda Chrome, local Chrome, iOS simulator, and Android emulator. Install the dependencies needed for the selected target.
Capture references. Run loki update to create or update reference files from the current Storybook stories.
Run comparisons. Run loki test after a code change to identify visual differences.
Review diffs. Inspect the diff folder. Decide whether each change is an expected design update or a regression.
Approve intended changes. Run loki approve to accept the new references when the changes are intentional.

# Terminal 1: start Storybook using your project's existing script.
npm run storybook

# Terminal 2: capture the current references.
npx loki update

# After making a UI change, compare it with the references.
npx loki test

# Inspect Loki's generated diff folder, then accept changes only when intended.
npx loki approve

The commands above illustrate the repository’s documented sequence; the Storybook start script and Loki installation method depend on your project. Do not approve references automatically before reviewing diffs, or the baseline can absorb an unintended change.

How Percy’s workflow works

Percy captures snapshots during tests, compares them with previously approved baselines, highlights visual changes, and lets reviewers approve intended changes or request fixes. Its documentation describes CI and source-control integration, so teams can make review part of a build workflow.

Connect the project and CI workflow. Follow Percy’s current setup instructions for the framework and source-control provider you use.
Run snapshot capture in the test or build. A Percy build groups the captured snapshots for comparison and review.
Inspect the comparison. Review changed snapshots and decide whether the UI change is intentional.
Approve the baseline when appropriate. Approved snapshots become references for later comparisons.
Set browser coverage deliberately. Each browser snapshot counts separately toward monthly screenshot usage, so more browser configurations increase usage.

Percy’s managed browser and operating-system versions can change over time. Browser rendering can affect fonts, native controls, scrollbars, and the number of reported differences. If exact OS/browser versions matter to the comparison, consult the documented Automate configuration route and confirm the current setup details.

Which should you choose?

Choose Loki when

Your visual checks are centered on Storybook stories.
You want an open-source CLI workflow and control over where rendering and reference files run.
Your team can own starting Storybook, installing and maintaining the required browser or simulator dependencies, storing references, and reviewing diffs.
You want to evaluate its documented rendering targets, including local or containerized Chrome and mobile simulators or emulators.

Choose Percy when

You want a hosted build and snapshot review workflow with centralized approval.
You want the service’s documented CI and source-control integration model.
You need cross-browser visual testing and can plan usage around the fact that each browser snapshot counts separately.
You prefer managed rendering, or need to investigate its documented configuration options for particular browser and operating-system versions.

Questions to settle before adopting either

Which pages and components must be covered: Storybook stories only, or broader application flows too?
Which browsers, operating systems, and mobile environments are required?
Who owns deterministic test data, fonts, network access, and other sources of rendering variation?
Where should reviewers see diffs, and who is allowed to approve new references?
How will references be updated when a change is intentional?
For Percy, how many browser snapshots will each build produce, and do current plan limits fit that volume?
For Loki, who maintains the browser or simulator setup and the CI environment?

Browser coverage and rendering differences

More browser coverage can find browser-specific visual changes, but the snapshots need not look identical across rendering environments. Fonts may load or rasterize differently; controls and scrollbars can vary; and a browser or OS update can alter the result. Define the environments that matter to users, then keep those conditions as stable as the tool permits.

Loki’s repository documents several targets, but each target has its own setup and dependency requirements. Percy documents managed cross-browser rendering and browser selection; its managed OS and browser versions are updated over time. For a team that must compare specific OS and browser combinations, review the Automate configuration documentation. Neither list alone guarantees a match for every device used by your customers.

Baselines, approvals, and noisy diffs

A baseline is useful only when it represents a reviewed, intended state. Establish a clear approval owner and review process. When a diff appears, first decide whether the product changed intentionally; then investigate environmental variation such as missing fonts, animations, asynchronous content, or a changed browser version. Update a reference only after establishing that the captured state is the one the team wants to preserve.

In Loki, the documented workflow puts diff inspection and approval around local output and reference files. In Percy, reviewers use the service’s build and snapshot review flow. Teams should check how each workflow fits their branch policy, review permissions, and artifact retention requirements.

CI, reliability, and maintenance

Both approaches can be part of CI, but the responsibilities differ. Loki’s repository says the tool is intended to be runnable on CI and that the user must start Storybook or a simulator/emulator separately. This means your pipeline needs to bring up the right environment, wait until it is ready, run capture or comparison, and preserve or publish useful diff artifacts.

Percy documents CI and source-control integration around hosted builds and reviews. Your pipeline still needs to trigger captures at the right point and handle failed or incomplete builds. The service moves rendering and review into a hosted workflow, while usage, supported configurations, and history depend on current plan terms.

For either tool, make a failed capture visible as a failed check rather than silently accepting an old reference. Keep a small set of stable representative snapshots at first, and expand coverage once the pipeline produces repeatable captures.

Performance and cost

The cited documentation does not provide an independent, comparable speed benchmark or a reliable total-cost comparison. Runtime depends on the number of stories or pages, browser configurations, environment startup, and CI resource availability. Measure a representative build in your own pipeline before setting expectations.

Loki: The project is open source, but that does not make operating it cost-free. Account for engineering time, CI compute, browser or simulator setup, artifact storage, and ongoing maintenance. The repository describes low maintenance cost and reproducibility as aims, not as independently verified outcomes.
Percy: Review current plan pricing, screenshot limits, and build-history terms directly before choosing. Browser selection affects usage because each browser snapshot counts separately. The documentation dossier reports free-plan build history expires after 30 days and other plans include one year; these terms may change, so verify them before relying on them.
Either tool: Include the cost of triaging noisy changes and keeping references current. A raw subscription or infrastructure figure does not capture that operational work.

Common problems and fixes

Symptom	Likely cause	What to do
Loki cannot reach or capture Storybook.	Storybook was not started, is listening on a different address or port, or is not ready when capture begins.	Start Storybook explicitly, check the configured endpoint and port, and make CI wait for readiness before running Loki.
Loki fails to launch its browser or simulator.	The selected rendering target’s dependencies are missing or incompatible.	Confirm the target and its current prerequisites in the Loki repository. Install the dependencies for that mode and check the project’s current Node compatibility.
Many snapshots differ after a machine or browser change.	Rendering conditions changed, including browser/OS, fonts, or native controls.	Compare the environments and versions, restore required fonts and stable inputs, then review diffs before updating references.
Percy reports changes that seem unrelated to application code.	Managed browser/OS updates or variable page content can alter rendering.	Inspect the changed region and build context, stabilize changing content where possible, and confirm the browser configuration used for the snapshots.
Percy usage grows faster than expected.	Each selected browser snapshot is counted separately.	Check the current usage and plan terms, and select only the browser coverage your project needs.
Reviewers cannot tell whether a baseline change is intentional.	No clear owner or release process for reference approval.	Assign approval responsibility and include the relevant design or implementation context with the review.

Or skip the browser setup

If the task is to capture a website page rather than run Storybook component diffs, a screenshot API can avoid maintaining a browser capture script. ScreenshotNeo is a website screenshot API and MCP server for developers. It returns a PNG, JPEG, WebP, or PDF from one GET request. It is a separate option for page captures, not a replacement for Loki or Percy baselines and visual review.

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

Equivalent Python and Node.js calls:

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}`);
if (!res.ok) throw new Error(`Screenshot request failed: ${res.status}`);
await Bun.write('shot.webp', new Uint8Array(await res.arrayBuffer()));

See the ScreenshotNeo API documentation for request options. Cookie banners, newsletter popups, and chat widgets are removed before capture; each cleanup step can be turned off. Bot checks, blank pages, timeouts, failed loads, and cache hits cost nothing, with response headers identifying the page verdict and billing status. An MCP server provides take_screenshot, get_page_info, and capture_pdf tools for AI agents. The Free plan includes 1,000 screenshots per month without a card; paid plans start at $5 for 3,000 screenshots. Sign up for ScreenshotNeo’s free plan.

FAQ

Does Loki work without Storybook?

Loki is described by its project as visual regression testing for Storybook. The documented workflow assumes a running Storybook, so it is intended for that use case.

Does Percy only work with Storybook?

No. BrowserStack describes Percy as a broader visual testing and review service that can capture Storybook snapshots as part of its workflow.

Can I claim one is more accurate or faster?

The cited sources do not establish an independent head-to-head result for accuracy or speed. Compare both against representative pages and environments from your own application.

Are Percy build-history terms permanent?

No. Plan features and retention terms can change. Check current BrowserStack documentation and plan details before making a retention decision.

Sources

Loki project repository — project purpose, prerequisites, rendering targets, and CLI workflow.
BrowserStack Percy documentation — snapshot comparison, builds, review workflow, and integrations.
BrowserStack Percy cross-browser documentation — browser selection, usage counting, and managed rendering considerations.