Best Cypress Alternatives for Website Screenshot Testing

For website screenshot testing, the right Cypress alternative depends on what you want to replace. If you want to keep Cypress, add a visual-regression plugin or use a hosted visual-testing service. If you want a test framework with screenshot comparison built in, consider Playwright Test. Cypress can capture screenshots, but its documentation says it does not perform image comparison itself. A screenshot captured after a failed test is useful for debugging; it is not a comparison against an approved baseline.

For screenshot capture outside a browser test suite, ScreenshotNeo is an alternative to try first: it removes known consent banners, newsletter popups, and chat widgets before capture, and only clean shots are billed. It complements visual-regression testing; it does not replace the assertions and baseline review that those tests provide.

Choose the kind of alternative you need

“Screenshot testing” can mean capturing images during functional tests, comparing images to detect visual changes, or reviewing changes in a team workflow. These needs overlap, but the tools are not interchangeable.

What you need	Likely fit	Main trade-off
Keep Cypress and compare images locally	An open-source Cypress visual-regression plugin	You own baseline files, environment consistency, and review workflow.
Keep Cypress and review changes in a hosted workflow	A hosted visual-testing service with a Cypress integration	Check current browser coverage, data handling, pricing, and integration support with the provider.
Replace Cypress with a framework that includes screenshot assertions	Playwright Test	You must migrate and maintain the test suite; this is not a Cypress plugin.
Capture a page image or PDF through an API	ScreenshotNeo	It captures pages; you still need a visual-testing tool or your own comparison logic to approve and compare baselines.

Decide based on the test scope (component, page, or end-to-end flow), who owns baselines, which browsers and viewport sizes matter, how reviewers approve changes, and whether the capture environment can be kept consistent.

Keep Cypress: add local image comparison

Cypress describes open-source plugins that compare screenshots locally or in CI, often with image baselines stored alongside the code. This approach keeps image files and workflow under your control. It works best when your team is ready to manage baseline updates, deterministic test data, rendering consistency, and readable diff artifacts.

Cypress’s plugin catalogue lists community options including Cypress Image Snapshot, Cypress Image Diff, and Visual Regression Diff. Package versions and Cypress compatibility change, so verify current package metadata and maintenance before choosing one. Do not assume a plugin is compatible with your Cypress version just because it appears in the catalogue.

Typical local-plugin workflow

Pick a plugin that supports your current Cypress version and CI runtime.
Install and configure it according to the plugin’s current documentation.
Capture a stable page or component state and save the initial baseline.
Review the baseline before committing it.
Run the same test in CI with the same browser and rendering environment.
Inspect image diffs when a test fails; update a baseline only after confirming the visual change is intended.

There is no single setup snippet that is valid for every plugin: their commands, thresholds, storage formats, and compatibility differ. Use the selected plugin’s official README for runnable setup instead of copying an API from another plugin.

This route is a good fit when you want to store baselines in version control, avoid sending screenshots to a vendor, and can provide a practical review process. It is a weaker fit if maintaining browser images and resolving noisy diffs consumes more effort than the tests save.

Keep Cypress: use a hosted visual-testing service

Cypress documents commercial visual-testing integrations that add hosted rendering, dashboards, pull-request review, or baseline approval workflows. The guide describes a range of approaches: AI-assisted comparisons, PR review, cloud rendering across browsers or responsive widths, component snapshots, DOM capture, region ignoring, and baseline management. These are descriptions in Cypress documentation, not independent comparative benchmarks.

Service named in Cypress documentation	Documented example of its focus	What to verify before choosing
Applitools Eyes	AI-assisted visual comparison	Current Cypress integration, supported browsers, review workflow, data retention, and price.
Argos	CI integration and pull-request review	Current integration support, limits, image handling, and plan details.
Chromatic	UI archive capture and cloud rendering and diffing	Whether its component workflow matches your test scope and current Cypress use.
Happo	Full-page and component snapshots across browsers and screen sizes	Current browser and viewport coverage and how baselines are approved.
LambdaTest SmartUI	Cloud screenshot comparison across browsers and resolutions	Supported combinations, integration details, retention, and price.
Percy	DOM snapshots rendered across browsers and responsive widths, with review and approval	Current Cypress support, rendering behavior, data policy, and plan limits.
Sauce Labs Visual	Baseline creation, region ignoring, and DOM capture	Current feature availability, integration support, and pricing.
SmartBear VisualTest	Full-page, element, and multi-device captures	Current capture options, supported browsers, and review workflow.
Wopee.io	Baseline management and review	Current Cypress compatibility, workflow, and commercial terms.

Start by checking the current provider documentation and terms. Confirm the supported Cypress versions, which browsers and viewport combinations it actually renders, whether it captures the live browser DOM or rerenders a snapshot, how reviewers approve changes, what screenshot data is retained, and the current pricing and usage limits. The research sources do not establish current prices or security terms for these services.

Choose a hosted option when PR-connected review, managed baseline workflows, or rendering coverage materially helps the team. Choose based on your actual test targets: a component-library team may need component snapshots, while an end-to-end suite may prioritize realistic page states and its existing Cypress flows.

Replace Cypress: use Playwright Test screenshot assertions

Playwright Test is the clearest framework alternative when you want screenshot assertions built into the test runner. Its toHaveScreenshot() assertion creates reference images on the first run and compares later runs against them. Reference images are stored with the tests and should be reviewed when updated. This is a framework migration, not a drop-in Cypress plugin.

Minimal runnable example, assuming Playwright Test is installed and its browser is available:

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

test('homepage matches its reference screenshot', async ({ page }) => {
  await page.goto('http://127.0.0.1:3000');
  await expect(page).toHaveScreenshot('homepage.png');
});

Run the test with your project’s Playwright Test command. On the first run, review and commit the generated reference image. Subsequent runs compare the current page to that file. Consult the Playwright visual-comparison documentation for current configuration and snapshot update commands.

Control volatile page content

Playwright documents options such as a maximum tolerated pixel difference and stylesheets that suppress volatile elements. For example, a stylesheet can hide a clock or animation that is irrelevant to the assertion. Configure these deliberately: an overly permissive threshold or broad hiding rule can conceal a real regression.

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

test('homepage visual state is stable', async ({ page }) => {
  await page.goto('http://127.0.0.1:3000');
  await page.addStyleTag({
    content: '.volatile-clock, .animated-decoration { visibility: hidden !important; }'
  });
  await expect(page).toHaveScreenshot('homepage.png', {
    animations: 'disabled',
    maxDiffPixelRatio: 0.01
  });
});

The numeric threshold above is an example configuration, not a recommended universal tolerance. Tune it against your page and inspect the resulting diffs. Keep the capture browser, operating system, browser settings, hardware, power conditions, and headless mode consistent with the environment that generated the references. Playwright warns that these factors can change screenshots.

Migration makes sense when the team is already standardizing on Playwright or wants its built-in screenshot assertions. Account for rewriting Cypress commands, fixtures, test setup, and CI integration, then compare the ongoing maintenance cost with extending Cypress.

Make screenshot comparisons reliable

A visual test is only useful when a change in the image reflects a change you care about. Cypress’s visual-testing guidance recommends waiting for the page to stabilize, using a consistent rendering environment, controlling time-dependent content and application data, and choosing appropriate visual targets.

Use deterministic data: seed records and avoid content that changes on every run.
Wait for the actual ready state: wait for a meaningful selector or application signal, not an arbitrary short delay when a better signal exists.
Control animation and time: disable nonessential animation and freeze clocks or dates where possible.
Keep rendering conditions stable: pin browser versions and run baselines and comparisons in the same operating environment.
Choose meaningful targets: capture a component for component behavior, a page for layout, or a full flow when the assembled experience matters.
Review every baseline change: an automated update can make a broken state the new expected image.

For Cypress, cy.screenshot() captures an image in cypress open or cypress run. During cypress run, failed tests are screenshotted automatically by default; the default output directory is cypress/screenshots. Cypress notes that it clears this directory before a run unless configured otherwise. These failure screenshots help diagnose tests; a visual-testing integration is still needed to compare an approved baseline.

Capture pages without running a browser test suite

When the task is to capture a URL as an image or PDF for a report, content workflow, or downstream review, an API can avoid managing a browser in your application. ScreenshotNeo is a website screenshot API and MCP server. Its capture options include full-page screenshots with lazy images loaded, CSS-selector element capture, viewport and device presets, dark mode, retina scale, PDF settings, custom CSS and JavaScript, selector waits, delays, network-idle waits, request blocking, custom headers and cookies, timezone and geolocation, caching with a chosen TTL, signed links, asynchronous jobs with signed webhooks, bulk capture of up to 100 URLs per call, and a usage API. See the ScreenshotNeo API documentation for parameter details.

It also has an MCP server with take_screenshot, get_page_info, and capture_pdf tools for Claude, Cursor, and other MCP clients. An API capture does not by itself decide whether an image should pass a visual regression test; compare it with an approved baseline using your chosen testing workflow.

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,
)
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}`);
const bytes = new Uint8Array(await res.arrayBuffer());
await import('node:fs/promises').then(fs => fs.writeFile('shot.webp', bytes));

These examples save the response body as an image. For production code, inspect the response status and headers, handle non-image responses according to the API documentation, and keep the API key out of client-side code. ScreenshotNeo supports PNG, JPEG, WebP, or PDF output and documents its request parameters at the API reference.

Or skip the browser setup

One GET request captures a URL. Cookie banners, popups, and chat widgets are removed before the shot. Bot checks, blank pages, and failed loads are never billed, and response headers say whether the page was clean and 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.

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

Performance, reliability, and cost

Local plugins: comparison runs in your local or CI workflow and image files are commonly kept with the code. The plugin category is described as free by Cypress, but budget engineering time for baseline reviews, storage, CI runtime, and flake investigation.
Hosted services: can provide managed rendering and review workflows, but pricing and usage limits vary. Check current vendor terms, screenshot retention, and data policies directly; no current prices are established here.
Playwright Test: avoids adopting a separate visual-comparison plugin for basic screenshot assertions, but migration and stable baseline maintenance have costs. Browser downloads, test runtime, and CI capacity also matter.
Screenshot API: can reduce browser infrastructure work for capture jobs. ScreenshotNeo charges only for clean shots; bot checks, CAPTCHAs, blank pages, timeouts, failed loads, and cache hits cost nothing. It offers Free 1,000 shots/month, Starter $5 for 3,000, Growth $15 for 15,000, Pro $39 for 60,000, Scale $99 for 250,000, and Business $249 for 1,000,000; yearly billing gives two months free. Every feature is on every plan.

Do not compare services on a price alone. Estimate capture volume, browser and viewport coverage, review time, CI resources, storage or vendor usage limits, and the engineering work required to keep tests deterministic. Recheck vendor prices and product details before purchase.

Troubleshooting screenshot tests

Symptom	Common cause	Fix
Images differ on every CI run	Different browser, OS, headless settings, fonts, hardware, or volatile data.	Generate and compare baselines in the same pinned environment; stabilize test data and time-dependent content.
Screenshot is blank or partially rendered	The capture ran before the app or important assets finished loading.	Wait for an application-ready selector or state and verify the page URL and test data before capture.
Diffs show animation frames or rotating content	Animation, carousels, clocks, or randomized content were not controlled.	Disable or freeze nonessential motion and data; mask only regions that are truly irrelevant.
Failure screenshot exists, but no visual comparison happens	Cypress’s failure artifact is being mistaken for a baseline assertion.	Add a visual-comparison plugin or hosted service, or use a framework with screenshot assertions.
Plugin command is missing or fails after upgrade	Plugin API or Cypress compatibility changed.	Check the plugin’s current installation instructions and supported Cypress versions; pin compatible versions.
Baseline update hides a real regression	References were refreshed without reviewing the visual change.	Inspect diff artifacts and approve intentional UI changes before committing new references.
Hosted integration behaves differently from local capture	The provider may render DOM snapshots or use a different browser, viewport, or environment.	Confirm the provider’s current rendering model and align its capture conditions with the behavior under test.
API output is not a usable image	The request may have returned an error or another response type.	Check HTTP status and response headers before saving bytes as an image; consult API parameter and error documentation.

Frequently asked questions

Does Cypress support screenshot testing?

Cypress supports screenshot capture. Image comparison requires an integration or another tool; Cypress’s visual-testing guide says comparison is not built into Cypress itself.

Is Playwright a Cypress plugin?

No. Playwright Test is a separate test framework. Its screenshot assertions can be a reason to migrate, but Cypress tests must be adapted to the new runner.

Should screenshot baselines live in Git?

Local plugins and Playwright commonly keep reference images with test code. That supports code review and versioning, but adds repository and review work. Hosted providers may manage baselines in their own workflow; check their current behavior and retention terms.

Can ScreenshotNeo replace a visual-regression service?

It captures screenshots and PDFs through an API and MCP server. Baseline comparison and approval remain a separate testing concern, so pair it with a comparison workflow when that is the goal.