Open-Source Alternatives to Happo for Website Screenshot Testing

Short answer: If your tests already use Playwright, start with Playwright Test’s built-in screenshot assertions. They keep screenshot capture, comparison, and reference images in your test workflow and repository. If you want a separate self-hosted visual-testing tool, BackstopJS is one option to investigate, but confirm its current maintenance, license, and setup from its own project documentation before adopting it. Neither choice gives you the same product workflow as Happo by default: Happo describes integrations with Storybook, Cypress, Playwright, and custom setups, along with hosted review and cross-browser capture. Happo’s product page describes those capabilities.

For a team whose main need is to capture a page image through an API rather than compare it to a version-controlled baseline, ScreenshotNeo is the alternative to try first: it removes cookie banners, popups, and chat widgets before capture, and only clean screenshots are billed. It is a screenshot API and MCP server, not a replacement for visual-regression assertions or baseline review.

What to look for in a Happo alternative

Visual regression testing captures a rendered interface and compares it with an accepted reference image. A diff can reveal layout, color, typography, or other visible changes that functional tests may not check. The choice is mainly about where capture runs, where baselines live, how changes are reviewed, and how stable the rendering environment is.

Decision	What to check
Existing test framework	Playwright-native assertions fit an existing Playwright suite. A Storybook workflow may fit teams that treat component stories as their test cases.
Hosting and ownership	Repository-managed baselines and a self-hosted runner give you control over the capture infrastructure. A hosted service provides cloud review infrastructure but depends on that service.
Capture environment	Find out which browser and operating system produce the screenshot, and whether the same environment can be used for baseline updates and comparisons.
Determinism	Plan for animations, timestamps, rotating content, asynchronous data, and other UI that changes between runs.
Review process	Decide who approves intentional changes, how diffs appear in pull requests, and how baseline updates are checked in.
Maintenance	Before selecting a standalone project, verify its current license, releases, browser support, dependencies, and integration instructions from first-party sources.

Options at a glance

Option	Best fit	What to know
Playwright Test screenshot assertions	Teams already running Playwright tests	Built into Playwright Test. It creates a reference screenshot on first run and compares later runs. You manage the test suite and image baselines in your project.
BackstopJS	Teams seeking a standalone, self-hosted visual-regression approach	A recent comparison names it as a free, self-hosted option. That comparison is vendor-authored, and the research available for this article did not establish current first-party maintenance, licensing, or setup details. Verify those before committing.
Argos	Teams considering an open-source visual-testing platform	The available source describing it as open source is published by Argos itself. Confirm the exact license, self-hosting scope, and current project terms in its primary documentation before deciding.
Chromatic	Teams centered on Storybook stories	Storybook’s documentation describes Chromatic as a cloud service for visual tests. It is a useful workflow comparison, but the sources reviewed do not establish it as an open-source replacement.
ScreenshotNeo	Teams that need screenshot capture by API or an MCP server for AI agents	It captures PNG, JPEG, WebP, or PDF and provides controls such as full-page capture, element capture, and custom CSS. Capture alone does not provide the repository-based regression assertions shown below. See the ScreenshotNeo documentation.

Start with Playwright Test

For a Playwright-based project, add an assertion after navigating to the state you want to preserve. The first execution creates a reference image; subsequent executions compare against it. The official Playwright visual comparisons guide explains snapshot naming, updating, comparison options, and environment consistency.

1. Install Playwright Test

npm install --save-dev @playwright/test
npx playwright install chromium

2. Add a test

Save this as tests/homepage.spec.ts. Replace the example URL with an application route that is available in your test environment.

import { test, expect } from '@playwright/test';

test('homepage visual baseline', async ({ page }) => {
  await page.goto('http://127.0.0.1:3000/', { waitUntil: 'networkidle' });
  await expect(page).toHaveScreenshot('homepage.png', {
    fullPage: true,
    animations: 'disabled',
    maxDiffPixels: 100,
  });
});

The first run writes the expected image. Review that image before accepting it into version control. A normal later run compares the rendered result with the checked-in reference.

3. Configure a consistent project

Use a project configuration so test execution and snapshot naming are explicit. Keep browser, operating system, fonts, and other rendering inputs consistent between baseline creation and comparison. Playwright warns that rendering can vary with the host OS, browser version, settings, hardware, power state, and headless mode.

import { defineConfig } from '@playwright/test';

export default defineConfig({
  testDir: './tests',
  use: {
    browserName: 'chromium',
    baseURL: 'http://127.0.0.1:3000',
  },
  expect: {
    toHaveScreenshot: {
      maxDiffPixels: 100,
      animations: 'disabled',
    },
  },
});

Run the suite with npx playwright test. When a visual change is intentional, inspect the diff and update references with npx playwright test --update-snapshots, then review and commit the changed snapshot files along with the code. Do not treat a bulk baseline update as approval by itself.

Useful Playwright controls

• fullPage: true captures the full scrollable page; omit it when the viewport alone is the contract you want to test.
• animations: 'disabled' suppresses CSS animations and transitions during capture. It does not make application state deterministic on its own.
• maxDiffPixels sets a pixel-count tolerance. Start with a strict threshold and increase it only when you understand the source of harmless rendering noise.
• stylePath applies a stylesheet during capture. Use it to hide known volatile elements, such as a timestamp or embedded content, rather than hiding broad regions that could contain real regressions.
• Give snapshots descriptive names, and use Playwright’s snapshot path configuration if your repository needs a custom layout. Snapshot paths remain subject to Playwright’s test snapshot rules.
• For multiple browser or platform projects, treat each rendering environment as its own baseline context. Images can differ across browser and platform combinations.

Choosing between the options

Use Playwright assertions when the test suite is the product

This is the most direct path when your application already has Playwright tests and you want expected images alongside those tests. It avoids introducing a second capture workflow. Your team still needs to manage snapshot files, consistent execution environments, and the review of changes.

Investigate BackstopJS when you need a separate self-hosted workflow

BackstopJS is named as a free, self-hosted alternative in an Argos-authored comparison. Treat that as a lead, not an independent project audit. Before adopting it, check its own current repository and documentation for maintenance activity, license, supported browser setup, and integration instructions. The research for this article does not establish those details, so it would be misleading to give version-specific setup commands or assert a current maintenance status.

Consider Argos with source verification

The available comparison is published by Argos and characterizes Argos as an open-source visual-testing platform. Because that description comes from the vendor, independently verify the project license and what can be self-hosted before making it a requirement. Do not infer that every hosted review feature can run on infrastructure you control.

Keep Chromatic distinct from the open-source shortlist

Storybook’s documentation describes Chromatic as a cloud service that captures stories, compares them with baselines, and presents visual changes for review. That makes it relevant for Storybook-centric teams, but it does not make it an established open-source alternative. Storybook’s guidance also says teams need to pause JavaScript-driven animations themselves to avoid false-positive diffs; CSS animations, transitions, videos, and GIFs are handled by its capture workflow.

Make screenshot comparisons reliable

1. Pin the capture environment. Use the same operating system, browser version, fonts, viewport, and relevant browser settings for baseline and comparison runs. Browser rendering differs across environments.
2. Choose stable application states. Seed or mock data where appropriate, and make sure the page has reached the state the test is intended to protect before taking the screenshot.
3. Control motion and time. Disable animations when they are irrelevant to the check. Freeze or remove changing timestamps and rotating content where possible. For JavaScript-driven animation, add an application-level test control; browser capture tools cannot infer the intended frame.
4. Wait for the page you need. A generic network-idle condition can be unsuitable for pages with long polling or persistent requests. Prefer an application-ready signal or a selector that indicates the target content has rendered.
5. Scope the assertion. Use a locator screenshot for a component when the component is the subject of the test. Use a full-page image when cross-section layout and page flow matter. Smaller assertions are often easier to diagnose.
6. Review diffs before updating baselines. Determine whether the change is expected, inspect affected regions, and update only the appropriate references.

Costs, performance, and ownership

Playwright’s built-in assertions avoid a separate visual-comparison service in the basic workflow, but they do not make capture free in engineering time: CI still runs browsers, images must be stored and reviewed, and someone must keep the environment stable. The reviewed sources do not provide a neutral performance benchmark across these tools, so there is no supported basis for ranking their speed.

A hosted workflow can provide cloud capture and review infrastructure; a self-managed setup gives your team responsibility for browser installation, operating-system consistency, storage, CI capacity, and baseline review. Compare total operating effort as well as any service price. The available research does not verify current prices for Happo, Argos, or other alternatives.

For reliability, the main risk is a noisy test that fails on irrelevant rendering differences or a test that misses a real change because volatile regions were hidden too broadly. Prefer deterministic data and narrowly scoped masking over raising a global pixel tolerance. Keep the baseline environment documented and make snapshot updates visible in code review.

Or skip the browser setup

If you need a screenshot image rather than a regression assertion, ScreenshotNeo can return an image with one GET request. Use it alongside your test workflow when useful; it does not replace comparing the result to a reviewed baseline. See the ScreenshotNeo API documentation.

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

import requests

r = requests.get(
    "https://api.screenshotneo.com/v1/shot",
    params={"access_key": "YOUR_API_KEY", "url": "https://stripe.com"},
    timeout=90,
)
r.raise_for_status()
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', res);

ScreenshotNeo removes cookie banners, popups, and chat widgets before the shot. Bot checks, blank pages, and failed loads are never billed. Its MCP server lets AI agents take screenshots. The free plan includes 1,000 screenshots per month with no card; paid plans start at $5 for 3,000. Sign up for 1,000 free screenshots a month, with no card.

Troubleshooting

Symptom	Likely cause	Fix
First Playwright run reports a missing snapshot	No reference has been created yet.	Inspect the generated screenshot, then add the accepted snapshot to version control. The first run is baseline creation, not a passing comparison.
Snapshots fail only in CI	CI and local runs may differ in OS, browser version, fonts, hardware, or headless settings.	Generate and compare in the same pinned environment. Avoid updating a baseline locally if CI uses a different rendering environment.
Repeated diffs affect timestamps, ads, or live content	The page contains time-dependent or externally changing regions.	Seed stable data or use a narrowly scoped screenshot stylesheet to hide the volatile region. Check that the masked area cannot conceal the UI behavior under test.
Screenshot captures an incomplete page	The page was captured before application data or target content finished rendering.	Wait for a meaningful application-ready selector or state before asserting. Do not rely on an arbitrary delay unless the page offers no better readiness signal.
Pixel tolerance hides meaningful changes	A global threshold may be too permissive for the component or page.	Lower the threshold or split the page into more focused assertions. Review the actual diff rather than treating a passing threshold as proof that the UI is correct.
Updates replace many reference files	The command updated baselines across multiple tests or environments.	Review each changed image and snapshot name, then revert unrelated updates. Update only the intended project or test where possible.
BackstopJS setup or license is unclear	The sources reviewed here do not verify current first-party project details.	Consult BackstopJS’s current repository and documentation for installation, license, browser dependencies, and maintenance before adopting it.

FAQ

Is Playwright screenshot testing open source?

This guide recommends Playwright Test’s documented built-in screenshot assertions as the practical starting point for a Playwright suite. Confirm the current license and project terms from Playwright’s own project materials if license status is a procurement requirement.

Can I use screenshots as a complete substitute for functional tests?

No. Screenshot comparisons detect visible changes; they do not by themselves verify that a button works, data is correct, or accessibility requirements are met. Keep behavior and accessibility checks in the test strategy.

Does ScreenshotNeo compare screenshots with a baseline?

The product facts provided for this article describe ScreenshotNeo as a screenshot API and MCP server. They do not establish repository-based visual regression assertions or baseline review, so use a test framework or comparison workflow for that job.

Which option is fastest?

The reviewed sources do not establish a neutral performance ranking. Measure in your own CI with representative pages, browsers, and review steps, and include setup and maintenance time in the comparison.

Sources

• Playwright: Visual comparisons — screenshot assertions, baselines, update behavior, comparison settings, and environment cautions.
• Happo — its stated integrations and browser coverage.
• Storybook: Visual tests — Chromatic workflow and Storybook visual-testing context.
• Argos comparison of BackstopJS and alternatives — vendor-authored context for BackstopJS and Argos; verify project-specific details independently.