Cypress vs Selenium: Which Should You Use in 2026?

Cypress vs Selenium: What Are the Differences?

Cypress is a JavaScript and TypeScript framework that runs your test code inside the browser, next to your app. Selenium is a W3C WebDriver library with bindings for five languages that drives the browser from outside. The table compares them as of 6 November 2026.

Version numbers and dates come from the Cypress package on npm and the Selenium package on PyPI. Both projects ship every few weeks, so re-check them before you commit.

Weighing a third framework? Read Playwright vs Selenium for that pair, or the Playwright vs Selenium vs Cypress comparison for all three on one page.

Cypress or Selenium: Which Should You Pick?

Pick Cypress for a web-only app tested by a JavaScript team that wants quick feedback in the browser. Pick Selenium when a requirement only it meets, such as another language, real Safari, several tabs or Appium, decides the question before preference does.

How Do Cypress and Selenium Work Under the Hood?

Cypress executes your test code inside the browser, in the same run loop as the application, and uses a Node process for work the browser cannot do. Selenium keeps test code outside the browser and sends each command to a browser driver over WebDriver.

Cypress: Tests Run Inside the Browser

Because test code is evaluated in the browser, Cypress can read the DOM, stub network calls and watch the app directly. The same design explains the JavaScript-only rule. The Cypress trade-offs page adds that work outside the browser, such as seeding a database, goes through cy.task() or cy.request().

Selenium: Commands Travel Through a Driver

Selenium sends each command as a request to a driver such as chromedriver or geckodriver, which controls the browser. That separation is why one API works from five languages and why a remote Grid can host the browsers on other machines. Each command is a round trip, so waiting and synchronization are your job.

• Cypress gains - direct DOM access, automatic retrying and a runner that shows every command with a DOM snapshot.
• Cypress gives up - other languages, more than one browser at a time and free control of several tabs.
• Selenium gains - language choice, any WebDriver-compliant browser and a standard that several vendors implement.
• Selenium gives up - built-in waiting, a built-in runner and the in-browser debugging view.

When Is Cypress the Right Call?

Cypress is the right call when a JavaScript or TypeScript team owns the tests, the app runs in one tab, and quick feedback while writing tests matters more than language choice or native mobile coverage.

• Same language as the app - front-end developers write and read the tests without learning a second stack. A Cypress tutorial gets a new team to a first passing spec quickly.
• Debugging in the runner - the Command Log shows each step with DOM snapshots you can step back through after a failure.
• Automatic retrying - queries and assertions retry until they pass or time out, which removes most hand-written waits.
• Network control - cy.intercept() stubs or observes requests from inside the test, with no extra proxy.
• Component and end-to-end testing - one tool covers both, so a front-end team keeps one set of habits.

Cypress also has limits: JavaScript and TypeScript only, one tab, and no native mobile.

When Is Selenium Still the Right Call?

Selenium is still the right call when your requirement is something Cypress does not cover: a language other than JavaScript, real Safari, flows across several tabs, native mobile through Appium, or free parallel runs on your own Grid.

• Languages - Selenium has official Java, Python, C#, Ruby and JavaScript bindings, so a team keeps the language it already ships in.
• Branded Safari - safaridriver drives the real Safari application on macOS. Cypress runs a WebKit build in experimental mode.
• Tabs, windows and origins - the driver switches between them natively, which suits OAuth logins, payment popups and embedded widgets.
• Native mobile - Appium extends the WebDriver model to native iOS and Android apps, so one skill set covers web and app.
• Edge IE mode - Selenium can automate Internet Explorer mode in Edge, which matters for internal apps tied to legacy sites.
• Existing code - years of frameworks, integrations and hiring pool. A stable suite with a low failure rate is an asset, not a problem.

Selenium has trade-offs too, mainly waiting and setup work. If Selenium itself is the wrong fit, read the Selenium alternatives guide before assuming Cypress is the only exit.

Which Browsers, Tabs and Origins Can Each Tool Handle?

Selenium drives Chrome, Edge, Firefox and real Safari, and handles several tabs and origins natively. Cypress supports Chrome, Edge and Firefox, controls one tab, and needs cy.origin() whenever a test crosses origins.

• Cypress browsers - the Cypress browser documentation lists Chrome, Chrome for Testing, Chromium, Edge and Firefox. Electron is deprecated, and WebKit is experimental behind the experimentalWebKitSupport option.
• Cypress under WebKit - the same page lists cy.origin() and Test Replay as unsupported there.
• Selenium browsers - Chrome, Edge, Firefox and Safari, each through its own driver. The Selenium Safari documentation covers safaridriver and its one-time enable step.
• Cypress tabs - Cypress does not control more than one open browser at a time, and its trade-offs page points to the @cypress/puppeteer plugin for multi-tab tests.
• Hosting the browsers - real Safari runs only on macOS, and older browser versions are hard to keep on local machines or CI runners, so wide coverage usually means maintaining a pool of machines.
• Cypress origins - since Cypress 14.0.0, cy.origin() is required whenever a test navigates between two origins. The cy.origin() reference notes that a few commands, such as cy.intercept() and cy.session(), belong outside the callback.

If your app has OAuth logins, payment popups or embedded widgets, automate one of those flows in Cypress before you commit to it. A flow that fits inside one origin and one tab raises none of these limits.

Which Is Less Flaky, Cypress or Selenium?

Neither is flaky by design; flakiness comes from timing, test data and shared state. Cypress retries queries and assertions automatically, while Selenium waits only where you write a wait, so a missed wait is its usual cause of intermittent failures.

• Cypress retrying - the Cypress configuration reference sets defaultCommandTimeout to 4000 milliseconds. Network calls are not awaited unless you alias them with cy.intercept() and wait on the alias.
• Cypress test retries - the retries option defaults to 0 for both run mode and open mode, so you opt in. The Cypress flaky tests guide covers retries and root causes.
• Selenium waiting - the implicit wait defaults to 0, so a missing element fails at once. Use explicit waits and avoid mixing them with implicit waits, as the Selenium waits guide explains.
• Environment drift - a CI runner whose Chrome or Firefox version has drifted can fail a test that passes on a laptop, and a run with no logs, video or screenshots is hard to tell apart from a flake.
• Retries hide problems - a retried pass still marks a flaky test, so log every retry instead of letting it disappear. The flaky test guide covers detection.

In practice, a well-written Selenium suite with disciplined waits and a Cypress suite with sensible retries fail at similar rates. The difference is who is responsible for the waiting: the framework in Cypress, your code in Selenium.

Can Cypress or Selenium Test Mobile Apps?

Neither automates a native mobile app on its own. Selenium reaches native iOS and Android apps through Appium, which speaks the same WebDriver protocol, while Cypress only resizes the viewport to simulate mobile screens.

• Selenium with Appium - a separate open-source project that keeps your language, runner and page-object structure. Appium vs Selenium explains how the two split the work.
• Cypress - cy.viewport() sets the screen size, and the trade-offs page states there is no native or mobile events support.

For a mobile web check, a resized Cypress viewport is a quick smoke test. For touch behavior or a real mobile browser, use Selenium against mobile browsers.

How Do Parallel Runs and Cost Compare?

Both frameworks are free, so cost comes from running them in parallel. Cypress parallel runs need Cypress Cloud, while Selenium parallelizes through your test runner and a Selenium Grid that you host yourself.

• Cypress - the Cypress parallelization documentation states that running tests in parallel requires the --record flag. Cypress Cloud has a free plan and paid plans, so check its pricing page for current limits.
• Selenium - TestNG, JUnit 5 or pytest-xdist start several sessions at once, and Grid routes them to browsers on other machines. The Selenium Grid setup tutorial shows the build.
• Hidden cost - a self-hosted Grid is free software but costs machines, patching and time, which is the usual reason teams rent hosted browsers. Neither side scales with the suite by itself: Cypress needs a larger Cypress Cloud plan and Selenium needs more Grid machines.

Which Tool Has Better AI Support?

Of the two, only Cypress has a built-in AI command: cy.prompt, in beta since version 15.13.0, turns plain-English steps into Cypress commands and needs a Cypress Cloud account. Selenium has no official agent tooling.

• Scope - the cy.prompt reference lists end-to-end tests only, with no component testing.
• Browsers - cy.prompt supports Chromium-based browsers only, which means Chrome and Edge.
• Language - prompts are optimized for English, and other languages are not guaranteed.
• Selenium - the project ships no official agent tooling.

Treat generated steps as a draft. Read the commands cy.prompt produces, keep your own assertions, and review the output the way you would review a pull request.

Cypress vs Selenium Code: The Same Login Test Four Ways

The same login test written four times shows the practical difference: Cypress needs no wait code and retries its assertion, while Selenium needs an explicit wait before each interaction that depends on page state.

Each test opens the login page of the TestMu AI ecommerce playground, signs in with credentials from environment variables, and checks that the browser lands on the account page. Register an account on the playground first. These samples are written against current APIs but have not been run for this guide, so run them once before you copy them into a suite.

Cypress (JavaScript)

Install with npm install cypress --save-dev and open the runner with npx cypress open; the install Cypress guide covers the setup. Export CYPRESS_SHOP_EMAIL and CYPRESS_SHOP_PASSWORD, and save the spec as cypress/e2e/login.cy.js.

describe('login', () => {
  it('lands on the account page after sign in', () => {
    cy.visit('https://ecommerce-playground.lambdatest.io/index.php?route=account/login');

    // cy.env() reads the CYPRESS_* variables and keeps the values out of the Command Log
    cy.env(['SHOP_EMAIL', 'SHOP_PASSWORD']).then(({ SHOP_EMAIL, SHOP_PASSWORD }) => {
      cy.get('#input-email').type(SHOP_EMAIL, { log: false });
      cy.get('#input-password').type(SHOP_PASSWORD, { log: false });
    });

    cy.get("input[value='Login']").click();

    // Retries until the URL matches or the default timeout hits
    cy.url().should('include', 'route=account/account');
  });
});

Selenium (JavaScript)

Install with npm install selenium-webdriver. Selenium Manager downloads a matching driver, so no driver setup is needed. Export SHOP_EMAIL and SHOP_PASSWORD before you run it with node.

const { Builder, By, until } = require('selenium-webdriver');

const LOGIN_URL = 'https://ecommerce-playground.lambdatest.io/index.php?route=account/login';

(async function loginTest() {
  const driver = await new Builder().forBrowser('chrome').build();
  try {
    await driver.get(LOGIN_URL);
    // Explicit wait: nothing waits for you unless you ask
    const email = await driver.wait(until.elementLocated(By.id('input-email')), 10000);
    await email.sendKeys(process.env.SHOP_EMAIL);
    await driver.findElement(By.id('input-password')).sendKeys(process.env.SHOP_PASSWORD);
    await driver.findElement(By.css("input[value='Login']")).click();
    await driver.wait(until.urlContains('route=account/account'), 10000);
    console.log('Login test passed');
  } finally {
    await driver.quit();
  }
})();

Selenium (Python)

Install with pip install selenium. Selenium Manager has been bundled since Selenium 4.6, so no driver download is needed. Framework patterns are in the Selenium Python guide.

import os

from selenium import webdriver
from selenium.webdriver.common.by import By
from selenium.webdriver.support import expected_conditions as EC
from selenium.webdriver.support.ui import WebDriverWait

LOGIN_URL = "https://ecommerce-playground.lambdatest.io/index.php?route=account/login"


def test_login_lands_on_account_page():
    driver = webdriver.Chrome()  # Selenium Manager resolves the driver binary
    try:
        wait = WebDriverWait(driver, 10)
        driver.get(LOGIN_URL)
        # Explicit wait: nothing waits for you unless you ask
        wait.until(EC.visibility_of_element_located((By.ID, "input-email"))).send_keys(os.environ["SHOP_EMAIL"])
        driver.find_element(By.ID, "input-password").send_keys(os.environ["SHOP_PASSWORD"])
        driver.find_element(By.CSS_SELECTOR, "input[value='Login']").click()
        wait.until(EC.url_contains("route=account/account"))
    finally:
        driver.quit()

Selenium (Java)

Add the org.seleniumhq.selenium:selenium-java dependency. Selenium Manager resolves the driver here too. For project structure with TestNG or JUnit, see Selenium Java.

import org.openqa.selenium.By;
import org.openqa.selenium.WebDriver;
import org.openqa.selenium.chrome.ChromeDriver;
import org.openqa.selenium.support.ui.ExpectedConditions;
import org.openqa.selenium.support.ui.WebDriverWait;

import java.time.Duration;

public class LoginTest {
    public static void main(String[] args) {
        WebDriver driver = new ChromeDriver(); // Selenium Manager resolves the driver binary
        try {
            WebDriverWait wait = new WebDriverWait(driver, Duration.ofSeconds(10));
            driver.get("https://ecommerce-playground.lambdatest.io/index.php?route=account/login");
            // Explicit wait: nothing waits for you unless you ask
            wait.until(ExpectedConditions.visibilityOfElementLocated(By.id("input-email")))
                .sendKeys(System.getenv("SHOP_EMAIL"));
            driver.findElement(By.id("input-password")).sendKeys(System.getenv("SHOP_PASSWORD"));
            driver.findElement(By.cssSelector("input[value='Login']")).click();
            wait.until(ExpectedConditions.urlContains("route=account/account"));
        } finally {
            driver.quit();
        }
    }
}

Count what each version does not contain. The Cypress test has no wait calls, no driver management and no runner setup, but it can only be written in JavaScript or TypeScript. The Selenium versions are longer and explicit, and the same test ports to any of the five languages.

Is It Worth Migrating Between Cypress and Selenium?

It is worth it only when a concrete limit costs you more than a rewrite would, such as Cypress blocking a multi-tab flow or Selenium waits driving your failure rate. A stable suite in either tool should usually stay where it is.

• Selenium to Cypress - the tests must become JavaScript or TypeScript, and most explicit waits disappear.
• Cypress to Selenium - you add a test runner and wait logic, and gain language choice, real Safari and several tabs.
• Either direction - move one high-value flow first, run both in CI side by side, and retire the old test only after the new one stays green through several releases.

How Do You Run Cypress and Selenium Tests at Scale?

Point both frameworks at a hosted grid and change only how the browser session is created. Your tests, language and framework stay as they are.

At scale, the real work is infrastructure: browsers and versions to keep current, parallel capacity, a grid or runners to keep alive, evidence when a run fails, and a way to reach localhost or staging. A hosted grid takes that upkeep off the team. TestMu AI Automation Cloud, cloud test automation infrastructure with AI-native debugging, runs existing Cypress and Selenium scripts across 3,000+ browser and OS combinations in parallel, with network logs, console logs, video and screenshots captured on every run.

• Capabilities - generate the browser, version, OS and build settings with the capabilities generator instead of writing them by hand.
• Credentials - store LT_USERNAME and LT_ACCESS_KEY as masked CI secrets and never commit the access key.
• Rollout - run one configuration first to confirm the wiring, then fan the matrix out in parallel.
• HyperExecute - for large suites, this orchestration engine splits tests across parallel nodes and retries flaky ones, running up to 70% faster than traditional grids.

Setup steps are in the docs: getting started with Cypress testing on TestMu AI and running your first Selenium test on TestMu AI. Take the exact hub endpoint and capability keys from the capabilities generator in the documentation rather than copying them from a blog post.

What Should You Do Next?

Test your riskiest flow in both tools. Write one real flow, ideally one with a popup or a second origin, run it 20 times in each, and compare the failure counts and the lines of wait code. That gives you an estimate for your own app in an afternoon.

If the flow fits Cypress and your team writes JavaScript, start there. If you need Safari, tabs, another language or Appium, keep Selenium. Leaving working tests alone is a valid result of this comparison.

To build Cypress skills before you decide, the Cypress 101 certification walks through the framework step by step.