Skip to content

Cross-Browser Testing with Cypress

Cypress supports running the same test suite across several real browsers. This lesson covers how to configure cross-browser runs and how to decide what genuinely needs that level of coverage.

Browsers Cypress Supports

Cypress supports Chrome, Edge, and other Chromium-based browsers, along with Firefox, using browsers already installed on the system (or CI image), plus a bundled Electron browser used by default, which requires no separate installation.

npx cypress run --browser chrome
npx cypress run --browser firefox
npx cypress run --browser edge

Each of these commands runs the exact same spec files, unmodified, against a different real browser engine.

Cross-Browser CLI Usage

cypress run --browser chrome
cypress run --browser firefox
cypress run --browser edge
cypress run --browser electron   // default, bundled browser
  • --browser accepts a browser family name or a specific path to a browser binary.
  • Electron is the default, bundled browser, requiring no installation but rarely representative of real user traffic.
  • CI images (like the official Cypress Docker images) typically include Chrome and Firefox pre-installed.
  • Safari and mobile browsers are not natively supported and typically require a separate cross-browser cloud service.

Cross-Browser Testing Cheat Sheet

Browser support and typical usage patterns for cross-browser Cypress runs.

Browser Support Level Typical Use
Chrome Fully supported Primary target, closest to most real users
Edge Fully supported (Chromium-based) Enterprise-heavy user bases
Firefox Fully supported Meaningful engine differences worth covering
Electron Default, bundled Fast local development, not representative of real users
Safari / Mobile Safari Not natively supported Requires a separate cross-browser cloud service

Deciding What Actually Needs Cross-Browser Coverage

Running an entire large suite across every supported browser on every CI run multiplies total run time significantly. A more sustainable strategy runs the full suite against one primary browser on every change, and a smaller, critical-path subset (or the full suite on a schedule) across the remaining browsers.

  • Run the full suite against your primary browser (usually Chrome) on every PR.
  • Run a smaller, critical-path smoke suite across other supported browsers on every PR.
  • Run the full suite across all browsers on a schedule (nightly) or before releases.

Handling Browser-Specific Configuration

Occasionally, a specific browser needs slightly different handling, a longer timeout for a known-slower engine on a particular action, or a workaround for a browser-specific rendering quirk. Cypress's config functions can branch based on Cypress.browser.name when this is genuinely necessary.

if (Cypress.browser.name === 'firefox') {
  cy.get('[data-cy="upload"]', { timeout: 10000 }).should('be.visible');
} else {
  cy.get('[data-cy="upload"]').should('be.visible');
}

Use browser-specific branching sparingly, it's a sign of a real difference worth documenting, not a habit to lean on casually.

Common Mistakes

  • Running the entire suite across every supported browser on every single commit, dramatically slowing CI feedback.
  • Assuming cross-browser Cypress support extends to Safari or real mobile browsers without additional tooling.
  • Writing extensive browser-specific branching logic for differences that could be fixed at the application level instead.
  • Never running cross-browser tests at all, missing real engine-specific regressions until users report them.

Key Takeaways

  • Cypress natively supports Chrome, Edge, Firefox, and the bundled Electron browser.
  • Safari and real mobile browsers need a separate cross-browser testing service.
  • A tiered strategy (full suite on primary browser, smoke tests elsewhere) balances coverage against CI time.
  • Branch on Cypress.browser.name only for genuine, necessary browser-specific differences.

Pro Tip

Reserve full cross-browser runs for a nightly schedule or pre-release gate rather than every single pull request, pair this with a small, fast critical-path smoke suite running across browsers on every PR, giving you both fast everyday feedback and periodic full-coverage confidence.