Most comparisons of these two read like a feature list, and feature lists do not help you choose. Almost everything that matters comes from one design decision, and once you know it you can predict the rest yourself.
Cypress runs inside the browser, in the same window as your app. Selenium drives the browser from outside, over a standard protocol.
That is the whole story. Everything below follows from it.
What running inside the browser buys Cypress
It feels fast, and the debugging is genuinely better than anything else. Cypress sits next to your application, so it can see the page directly with no round trip to another process. That makes retrying every command cheap, which is why Cypress can wait for things automatically without you asking.
It also produces the feature people miss most when they leave: a command log you can hover, showing the page at that moment in the test. When a test fails at step nine, you can look at step seven. For someone learning automation, this shortens the feedback loop enormously.
You write less setup. Cypress ships a test runner, an assertion library, and its waiting behaviour in one install. There is nothing to wire together.
What running outside the browser buys Selenium
Reach, and it is not close. Selenium is built on WebDriver, a W3C standard that browser makers implement themselves. That means Selenium works with more browsers, more languages and more operating systems than anything else: Java, Python, C#, Ruby and JavaScript, across Chrome, Firefox, Safari and Edge.
If your team writes Java, this is decisive on its own. A Java team will maintain a Java suite far better than a JavaScript suite nobody is comfortable in, and that matters more over three years than any feature.
No same-origin restriction, and no tab limit. Because Selenium is not page code, the browser's page-level security rules do not apply to it. Multiple tabs, multiple domains and multiple windows are ordinary work.
The limits you should know before choosing
These are the Cypress ones, and they are all predictable from "it runs inside the browser":
- One tab. A test cannot drive a second tab, because a tab cannot control another tab. Usually you check the link's
targetattribute instead. - Cross-origin needs care. Your test is page code, so it obeys the same-origin policy.
cy.origin()handles this and works, but it is extra machinery, and it is painful as a general pattern rather than for one login test. - Safari support is experimental. If a large part of your traffic is iPhone users, that matters.
- Free parallel running is limited. Cypress splits work by spec file, and the good load balancing is a paid product. Selenium parallelises through Grid, which you host and maintain yourself.
And the Selenium ones, which all come from "it is a library, not a framework":
- You build the framework. Selenium gives you browser control. No test runner, no assertions, no configuration, no reporting, and no automatic waiting. Every Selenium team writes those layers, and writing them badly is the usual reason a Selenium suite is unreliable.
- Waiting is your job. This is the single biggest source of flaky Selenium tests. Skipping an explicit wait is the classic mistake, and nothing in the tool stops you.
- It is structurally slower. Every command is an HTTP round trip to a driver process. On your laptop that is a millisecond. To a remote Grid it can be 30ms, and a chatty test pays it hundreds of times.
One myth worth correcting: driver version mismatches are mostly solved. Modern Selenium ships Selenium Manager, which finds and fetches the right driver for you. If you read a tutorial telling you to download ChromeDriver by hand and set a PATH variable, it predates that.
Speed, honestly
Cypress usually feels faster, and for a single test on one machine it often is. But at suite scale the picture changes: a well-built Selenium suite with proper parallel Grid capacity can finish a large run quickly, and a badly built Cypress suite that logs in through the form for every test will be slow no matter what.
The honest summary: the tool sets your floor, your setup decides your actual runtime. Most slow suites are slow because of user-interface setup and missing parallelism, not because of the tool.
Which should you choose?
Choose Cypress when:
- Your team writes JavaScript or TypeScript and will maintain the tests themselves.
- You are testing one web application, in one tab, on Chromium and Firefox.
- You want the shortest path from nothing to a working test, and the best debugging experience while learning.
Choose Selenium when:
- Your team does not write JavaScript. This is the strongest reason on the list.
- You need browsers or platforms other tools do not reach, including older browsers some enterprise customers still run.
- You already have a large, working suite that catches real bugs. That has value a rewrite would destroy for months.
- Your organisation needs a long-lived standard for compliance reasons. Selenium's age and its W3C standing are advantages there.
The answer people do not expect
If you are starting fresh in 2026 with a JavaScript team, the honest recommendation is often neither of these two: look at Playwright first.
It runs outside the browser like Selenium, so it has no tab or origin limits. It waits automatically like Cypress, so waiting is not your job. It runs Chromium, Firefox and WebKit, and its parallel running is free and built in.
That does not make Cypress or Selenium wrong. A working suite is worth more than a better tool, and migrating costs months to arrive at the coverage you already had. But if nothing is written yet, comparing only these two is comparing the wrong pair.
We teach all three here for that reason, and the ideas move across: locators, waiting, assertions and test data are the same job in every tool. Only the words change.
Remember this
Cypress trades freedom for a great developer experience. Selenium trades convenience for reach. Choose for your constraints, your team's language and the app you actually have, not for whichever tool a comparison article liked most.
Next: read the Cypress tutorial or the Selenium WebDriver tutorial, then write a real test in the practice editor and see which one you prefer working in.