Recommended Free Tools
Cypress can verify that a user journey works; Percy can add visual regression checks to catch unintended changes in how that journey looks. In a Cypress test, reach a stable page state, keep functional assertions, then call cy.percySnapshot(). Percy captures the DOM snapshot, renders it in its cloud across browsers and responsive widths, and presents visual changes for review. Cypress’s own screenshot command captures an image but does not compare it: “Cypress does not perform image comparison itself.” (Cypress visual testing documentation.)
What Cypress and Percy each do
Cypress drives a browser through an application and checks behavior: visiting pages, clicking controls, reading content, and exercising connected systems. End-to-end tests are useful for critical journeys but can take more setup and maintenance and may need dedicated backend and CI infrastructure. Cypress component tests mount a component in a real browser and offer a more focused surface for visual checks. (Cypress testing types; Cypress products.)
Percy, now part of BrowserStack, supplies hosted visual comparison and review. Cypress’s visual-testing guide describes cy.percySnapshot() capturing DOM snapshots during tests; Percy renders them in its cloud across browsers and responsive widths, then lets teams review and approve changes. Its integrations page describes CI/CD and code-review workflows, including pull/merge request connections and notifications. (Percy visual testing; Percy integrations.)
The two checks answer different questions. Functional assertions establish whether the application behaves as expected. A visual diff checks whether its rendered appearance changed relative to an approved baseline. Neither replaces the other, and appearance comparisons do not validate accessibility semantics, keyboard behavior, or color contrast.
The Tool Desk
Outbyte PC Repair FREEClear out junk files and repair common Windows errorsFree Scan →Outbyte Driver Updater FREEScan for outdated or missing drivers - takes under a minuteDriver Scan →Set up a Cypress visual snapshot
Install and configure Percy for Cypress using the current instructions in Cypress’s visual-testing guide, including the required project credentials and CI configuration. Package names and setup commands can change, so follow the guide for the version and environment you use rather than copying an outdated install command.
A typical test keeps Cypress assertions and adds a Percy snapshot only after reaching the state worth reviewing:
describe('checkout', () => {
it('shows the shipping step consistently', () => {
cy.visit('/checkout');
cy.get('[data-cy=shipping-address]').should('be.visible');
cy.get('[data-cy=shipping-address]').should('contain', 'Shipping address');
cy.percySnapshot('Checkout — shipping address');
});
});The example assumes that the project has installed and configured the Cypress-Percy integration and exposes cy.percySnapshot(). Replace the route, selector, and expected content with application-specific values. The assertion is not redundant: it confirms a meaningful readiness condition before the snapshot, while Percy checks appearance.
- Drive the application to a meaningful state. Use the same user interactions as the journey you want to protect, or use component testing when the visual question is local to a component.
- Assert readiness. Check that the relevant content or control is visible and correct before capturing. Avoid taking a snapshot while asynchronous rendering is incomplete.
- Capture a named checkpoint. Use a descriptive name that identifies the screen and state, such as a form with validation errors or a populated account summary.
- Run the test in the intended CI workflow. Percy compares the rendering with the approved baseline and presents changes for review.
- Review before updating the baseline. Fix unintended regressions. If the design change is intentional, approve the new rendering as the baseline through the configured review workflow.
Choose snapshots that answer a real question
Do not add a visual snapshot to every test by default. Select important user-facing states that reviewers can interpret and that would be costly to break. A checkout confirmation, a critical form state, or a navigation layout may be more useful than many nearly identical snapshots.
- Use an element-level snapshot when the question is limited to a component and unrelated page content would produce noise.
- Use a full-page snapshot when overall layout, page structure, or content flow is what you need to validate.
- Keep functional coverage alongside visual coverage. The visual comparison is not a substitute for assertions about navigation, submission, or application state.
Reduce noisy or unstable diffs
A visual comparison is only useful when the captured state is repeatable. Cypress’s guidance recommends waiting for the relevant interface to settle, using repeatable data, and controlling sources of variation where practical. (Cypress visual-testing guidance.)
- Wait for rendering and data. Use a readiness assertion tied to the visible state, not an arbitrary delay as the sole signal.
- Stub changing API responses or use fixtures. Repeatable content makes it easier to distinguish a genuine UI change from fresh data.
- Control time where dates or clocks appear. Freeze time for screens that display dates, countdowns, or time-sensitive labels.
- Mask only content that cannot be stabilized. Third-party widgets may be inherently dynamic; keep any masked region as small as possible so the test still checks the surrounding interface.
- Keep environments consistent for local pixel-diff tools. Hosted visual services may manage rendering consistency, but teams should still make their test state deliberate.
Choose hosted comparison or self-managed tooling
Cypress groups visual-testing approaches into open-source plugins and commercial services. Local or CI plugins can keep baselines with code and comparisons in the team’s environment, while requiring the team to manage baseline updates, rendering consistency, and diff review. Hosted services can provide managed comparison, baseline workflows, rendering, and web-based review in exchange for a subscription. The right choice depends on infrastructure ownership, review needs, coverage, and total cost.
| Decision point | Self-managed plugin or local/CI comparison | Hosted visual service such as Percy |
|---|---|---|
| Baseline ownership | Can be stored with code; the team manages updating and retaining them. | Service-managed workflow; confirm the specific service’s current controls. |
| Rendering environment | Team maintains consistent environments and comparison behavior. | Managed rendering is part of the hosted-service model; exact coverage depends on the service. |
| Review workflow | Team builds or maintains CI diff review and artifact handling. | Percy describes web review and CI/code-review integrations. |
| Coverage | Depends on the browsers and viewports the team configures. | Percy describes cloud rendering across browsers and responsive widths; the cited pages do not establish a specific browser matrix or viewport count. |
| Cost | May avoid a hosted subscription, but uses engineering time and CI resources. | Subscription terms and limits should be checked with the service; no price is asserted here. |
Cypress lists Percy and other integrations, including Applitools, Argos, Chromatic, Happo, LambdaTest SmartUI, Sauce Labs Visual, SmartBear VisualTest, and Wopee.io. That list identifies integrations, not a claim that the tools have identical features or are endorsed equally. (Cypress visual-testing integrations.) Cypress’s open-source Cypress App is MIT-licensed; Cypress Cloud has billing plans, including a free plan for recording CI runs, while premium UI Coverage and Accessibility have separate pricing. These are Cypress offerings, not Percy pricing; check current terms directly. (Cypress pricing FAQ.)
Where ScreenshotNeo fits
For teams that need a screenshot API rather than visual-diff review integrated into Cypress tests, ScreenshotNeo is an alternative to try first: it removes known consent banners, popups, and chat widgets before capture, bills only clean shots, and offers a low-cost paid entry plan. It is not a replacement for Percy’s baseline comparison and review workflow.
Or skip the browser setup
For a one-off or API-driven screenshot, make one GET request with the target URL. See the ScreenshotNeo API documentation for request options and response details.
curl -G "https://api.screenshotneo.com/v1/shot" -d access_key=YOUR_API_KEY --data-urlencode url=https://stripe.com -o shot.webpScreenshotNeo accepts cookie/consent banners and removes more than 60 known consent platforms, newsletter popups, and chat widgets before capture; each step can be disabled. Bot checks and CAPTCHAs, blank pages, timeouts, failed loads, and cache hits cost nothing, and responses report the page verdict and billing status. An MCP server provides take_screenshot, get_page_info, and capture_pdf for AI agents. The free plan includes 1,000 screenshots per month with no card; paid plans start at $5 for 3,000 shots.
Sign up free for 1,000 screenshots a month, with no card required.
Independent reader supportYour contribution helps us test, update, and keep practical guides available for everyone.Troubleshoot common problems
cy.percySnapshot is not a function: the Cypress-Percy integration may not be installed or initialized in the test setup. Follow the setup for your installed integration version and verify that it loads before the spec runs.- A snapshot captures a loading or empty state: add an assertion for the exact content or control that marks readiness, and make sure the test data or API response is available before capture.
- Differences appear on every run: identify changing text, dates, API data, animations, or third-party regions; stabilize them where possible and narrowly mask only the irreducibly dynamic area.
- A whole page changes when only one component matters: use an element-level snapshot if the integration supports that capture mode, or isolate the component with Cypress component testing.
- Intentional design changes keep appearing as diffs: review the change and approve the new baseline using the team’s configured Percy workflow rather than ignoring future comparisons.
- Local results do not match CI: for self-managed pixel comparison, align browser, viewport, fonts, and rendering environment; hosted services may reduce environment variation, but verify the chosen service’s behavior.
Performance, reliability, and cost considerations
Every added snapshot creates an artifact and a review decision, so snapshot count should track meaningful states rather than test count. Keep test data deterministic and capture after readiness checks to reduce reruns and reviewer time. End-to-end tests can require backend and CI infrastructure; component tests offer a narrower visual surface where that scope is sufficient. Hosted rendering shifts some environment and baseline-management work to a service but introduces subscription considerations. Cypress’s own app and Cypress Cloud pricing are separate from Percy’s service terms, which should be verified with BrowserStack for the plan in use.
Frequently Asked Questions
Does Cypress compare screenshots by itself?
No. Cypress’s built-in cy.screenshot() captures an image; a visual-testing plugin or service provides image comparison and review.
Does Percy replace Cypress assertions?
No. Keep assertions for behavior and readiness; Percy adds comparison of rendered appearance against an approved baseline.
Can I use visual checks without a full end-to-end test?
Yes. Cypress component testing mounts a component in a real browser and can provide a focused surface for visual checks.
Quick Recap
Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.
