Best Cypress Plugins for Testing

The best Cypress plugin depends on the testing problem you need to solve. Start with the task—filtering tests, collecting code coverage, checking accessibility, mounting components, comparing screenshots, or improving API and test reports—then verify that the package supports your Cypress version and fits your CI workflow.

Cypress’s plugin catalogue is a useful starting point, not a quality ranking. It distinguishes official, community, and deprecated entries. “Official” means maintained by Cypress; community packages have separate maintainers and are not reviewed by Cypress. Check the live catalogue and each package README before adopting a plugin because versions, support, and maintenance activity can change.

Choose by testing need

Need	Option to evaluate	What to check
Run selected tests by title or tag	`@cypress/grep`, listed by Cypress as an official option	Current Cypress compatibility and the documented registration in both support code and Node configuration.
Save code coverage collected during tests	`@cypress/code-coverage`, listed as an official plugin	How instrumentation, report generation, and CI artifact handling fit your app and pipeline.
Automated accessibility scans	`cypress-axe`, a community integration for axe-core; Cypress also lists an official Cypress Accessibility offering associated with Cypress Cloud	Which checks run locally versus through Cloud, and how findings are reviewed. Scans do not prove full accessibility.
Test framework components	Cypress mounting libraries for React, Angular, Vue, and Svelte	The current framework and bundler support matrix for your exact versions.
Visual regression	Local open-source screenshot comparison, Pixeleye’s self-hostable review platform with Cypress integration, or a managed visual testing service	Who maintains baselines, how changes are reviewed, browser coverage, rendering consistency, hosting, and cost.
API helpers or reporting	Catalogue entries in the API and reporting categories	Maintenance, compatibility, dependency footprint, output format, and CI integration. Treat entries as candidates, not endorsements.

Test selection and code coverage answer different questions: filtering chooses which tests to run; coverage records which application code those tests exercise. Cypress Cloud’s UI Coverage is a separate Cloud feature and is not the same thing as code coverage.

How to evaluate a Cypress plugin

Define the gap. Write down the repeated task or missing signal the plugin should address. Avoid adding a dependency simply because it appears in a catalogue.
Check its status and maintenance. Read the live Cypress catalogue entry and package README. Look at the latest release, open issues, supported Cypress versions, dependency footprint, and whether the package is deprecated.
Confirm where its code runs. Node-side setup belongs in setupNodeEvents; browser commands and imports belong in the support file. Some plugins need both.
Read the setup instructions for your project. Confirm your Cypress, framework, bundler, and package-manager versions. Component testing support is version-specific.
Try it on a representative test and CI job. Check runtime, reliability, output usefulness, and behavior on retries or parallel workers before expanding adoption.
Decide who owns upkeep. Assign responsibility for upgrades, test data, reports, visual baselines, and reviewing failures.

Install and register plugins correctly

Cypress describes plugins as versioned npm packages. Install a plugin as a development dependency using the package manager and follow its README; there is no universal registration snippet because some plugins run in Node, some in the browser, and some in both.

# Install a package as a development dependency
npm install --save-dev <package-name>

For a Node-side plugin, add its setup to the setupNodeEvents function in your Cypress configuration file. The outline below is illustrative: replace the placeholder with the plugin’s documented API.

// cypress.config.js
const { defineConfig } = require('cypress');

module.exports = defineConfig({
  e2e: {
    setupNodeEvents(on, config) {
      // Register Node-side plugin hooks here, following its README.
      // If the plugin changes config, return the updated config.
      return config;
    },
  },
});

For a browser-side command, add the documented import to the support file, commonly cypress/support/e2e.js. Use the actual import path and setup shown by the selected package.

// cypress/support/e2e.js
import '<plugin-package>/support';

Some integrations require both locations. Restart Cypress after configuration changes. If a Node plugin modifies the config object, return it so Cypress applies the changes. Avoid copying setup from an old tutorial without checking the current package README.

What to know about each plugin category

Test filtering

@cypress/grep can filter tests by title or tags. Cypress’s guide demonstrates registering it in the support file and Node configuration. Use the current guide for the exact setup and supported release, then make sure CI still runs the intended full suite on the schedule or branch where it matters. Filtering can shorten a targeted run, but a workflow that only runs selected tests can leave other tests unexecuted.

Code coverage

@cypress/code-coverage is listed in the catalogue as an official option for saving code coverage collected during tests. Coverage depends on the application being instrumented and on reports being collected and retained correctly. Keep the distinction clear in dashboards: code coverage tracks exercised code; UI Coverage is a separate Cypress Cloud feature.

Accessibility

Cypress documents cypress-axe as a community plugin integrating axe-core, with guidance for adding scans using checkA11y(). The catalogue also includes an official Cypress Accessibility offering associated with Cypress Cloud. Evaluate which workflow suits your project and where results need to appear.

Automated scans can catch useful classes of accessibility issues, but they cannot establish that an interface is fully accessible. Combine scans with manual checks and traditional assertions, including keyboard and assistive-technology review appropriate to the interface. Do not treat a clean scan as proof of conformance.

Component testing

Cypress documents official mounting libraries for React, Angular, Vue, and Svelte. Choose the integration for your framework, then consult Cypress’s current framework and bundler matrix. A package that works for one combination of framework and bundler may not support another or the versions in your repository.

Visual regression

Visual regression compares rendered output against screenshots or other baselines. Local open-source tools give the team control over comparison and baseline storage, but the team must maintain the review process and rendering environment. Cypress’s guide names Pixeleye as a self-hostable review platform with Cypress integration. Commercial services can manage baseline review and infrastructure.

Compare visual options by baseline ownership, review workflow, browser and viewport coverage, rendering consistency, hosting, and ongoing maintenance. Local pixel comparison and team-managed baselines can avoid a managed-service bill, while hosted services may provide managed infrastructure, broader browser or viewport runs, and a consistent rendering environment. Choose according to the review process your team can sustain; no comparative benchmark is established here.

API testing and reporting

The Cypress catalogue groups API helpers and reporting tools. These categories are broad, so inspect the individual package’s supported versions, documentation, issue activity, output format, and CI behavior. Confirm that the report answers a decision your team needs to make, rather than only adding another artifact to store.

Visual screenshot workflows and ScreenshotNeo

For a Cypress visual testing workflow, use Cypress and a suitable plugin or service to capture and compare the application pages your tests cover. ScreenshotNeo serves a different but adjacent need: capturing screenshots of websites through an API. If you need an API or MCP server for website screenshots, ScreenshotNeo is the first alternative to consider: it removes known consent banners, newsletter popups, and chat widgets before capture, and only clean shots are billed.

Or skip the browser setup

A single GET request can return a PNG, JPEG, WebP, or PDF. This runnable cURL example saves a WebP screenshot; replace the key with your ScreenshotNeo API key. See the ScreenshotNeo API documentation for 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.webp

ScreenshotNeo accepts cookie or consent banners like a visitor and removes more than 60 known consent platforms, newsletter popups, and chat widgets before the shot; each step can be turned off. Bot checks, blank pages, timeouts, failed loads, and cache hits cost nothing, and response headers report the page verdict and billing status. Its MCP server gives AI agents tools for screenshots, page information, and PDF capture. The free plan includes 1,000 screenshots per month with no card; paid plans start at $5 for 3,000 screenshots.

Performance, reliability, and cost

Runtime: A plugin can add setup, browser work, network calls, or report generation. Measure a representative local and CI run before rolling it out broadly.
Reliability: Check how failures appear, whether retries can hide flaky behavior, and how the plugin behaves with parallel jobs. Keep plugin errors distinguishable from application test failures.
CI artifacts: Decide where coverage and test reports are stored, how long they are retained, and who can access them. Ensure parallel workers do not overwrite shared outputs.
Visual baselines: Rendering differences can create noisy changes. Keep browser, viewport, fonts, data, and rendering conditions consistent where possible, and define who approves baseline updates.
Dependency cost: npm packages have maintenance and upgrade costs even when they are free. Managed visual services may add recurring charges; compare actual plan terms and required coverage before committing.
Review cost: A tool only helps if someone can triage its findings. Account for the time to review accessibility results, visual diffs, and reports.

Troubleshooting

Symptom	Likely cause	What to do
Plugin hook or command is undefined	Setup is in the wrong runtime or the support import is missing.	Check the README and register Node hooks in `setupNodeEvents`, browser commands in the support file, and both if required. Restart Cypress.
Configuration change has no effect	A Node plugin changed config but the updated object was not returned, or Cypress was not restarted.	Return the config from `setupNodeEvents` and restart Cypress after changing configuration.
Install succeeds but Cypress reports incompatibility	The package version does not support the installed Cypress version, or the tutorial targets a different release.	Check the catalogue’s supported-version details and the package README; choose a compatible version or integration.
Component mount fails in one project	The framework, bundler, or version combination is not supported by the selected mounting library.	Check Cypress’s current component framework and bundler support matrix for the exact project versions.
Coverage report is empty	The app may not be instrumented, collection may not run, or CI may not retain or merge output.	Follow the plugin’s instrumentation and reporting instructions, then inspect the artifacts from a single test run before debugging parallel aggregation.
Accessibility scan passes but users still encounter barriers	Automated checks cover only detectable rule violations and do not prove the interface works for everyone.	Add manual accessibility review and targeted assertions; include keyboard and assistive-technology checks where appropriate.
Visual diffs change between runs	Browser or viewport, fonts, data, timing, or rendering environment changed.	Stabilize those inputs, review whether the difference is real, and update a baseline only through the team’s review process.
Filtered CI run misses a regression	The workflow runs only a subset selected by titles or tags.	Keep a full-suite run in the appropriate CI schedule and verify that tags and selection rules include the intended tests.

Frequently asked questions

Are Cypress plugins all maintained by Cypress?

No. The catalogue separates official, community, and deprecated entries. Community packages have separate maintainers and are not reviewed by Cypress.

Does a plugin need to be installed in production dependencies?

Cypress describes plugins as versioned npm packages; install test tooling as a development dependency unless the package’s own instructions give a reason to do otherwise.

Does passing an automated accessibility scan mean a site is accessible?

No. Cypress explicitly advises that no automated scan can prove an interface is fully accessible and works well for users with disabilities. Use scans alongside manual checks and assertions.

How many plugins are in the Cypress catalogue?

The catalogue displayed 131 entries during the research for this article, but that inventory changes. Check the live catalogue for the current count.

Sources and next steps

Use the catalogue to shortlist candidates, then verify the README, compatibility, and ownership fit before adding a dependency.