Browse the Knowledge Hub32 resources

/Comparisons/Cypress vs Selenium

Comparison

Cypress vs Selenium: a product against a standard

One arrives with the runner, debugger and reporting decided for you. The other is the browser automation standard you build a framework around. Comparing them on features alone misses the point, so this compares what each actually costs to own, and says which teams should not switch at all.

2options/23dimensions/August 2026checked/Freeno sign-up

The short answer

These are not the same category of tool. Cypress is a product: runner, assertions, reporting and debugging arrive together and it decides how you will work. Selenium is a W3C standard with language bindings, around which you assemble a framework from a runner, an assertion library, reporting and a grid. Most of the disappointment on this decision comes from expecting Selenium to behave like a product, or expecting Cypress to bend like a library.

For a web application on a single origin, tested by a team comfortable in JavaScript, Cypress gets a trustworthy suite running faster and stays more pleasant to maintain. For an organisation that needs Safari and legacy browser coverage, has Java or C# engineers, already runs a grid, or wants the same patterns to extend into native mobile through Appium, Selenium remains the correct answer and is not going anywhere.

One thing worth saying plainly: if you are choosing today and neither of the above constraints is binding, evaluate Playwright alongside Cypress before you commit. It reaches most of Selenium's coverage breadth with a modern product experience, which narrows the situations where this particular comparison is the real decision.

Side By Side

23 dimensions that actually decide it

Download or copy the table if you are writing this up for a decision record.

Cypress

An opinionated end to end testing product for web applications, with the runner and debugger built in.

Open source core, MIT, Cypress Cloud paid per test result

Selenium

The W3C WebDriver standard with bindings in most languages, assembled into a framework by you.

Open source, Apache 2.0, costs are grid or device cloud

Dimension	Cypress	Selenium
What you are actually adopting
Product or standard Sets expectations for everything else, including how much you will build yourself.	A product with a runner, assertions, retries, video and reporting included.	A browser control standard. The framework around it is your responsibility.
Time to a first useful suite Decides whether automation survives its first quarter.	Days. Install, write, run, debug in the same tool.	Weeks. Runner, waits, page objects, reporting and CI wiring all need decisions first.
Language support The single most common reason large organisations stay on Selenium.	JavaScript and TypeScript only.	Java, Python, C#, Ruby, JavaScript and Kotlin, all officially maintained.
Browser coverage Safari and enterprise legacy targets are where this gap is decisive.	Chrome, Edge, Electron and Firefox. WebKit support has stayed experimental.	Chrome, Firefox, Edge and Safari as supported targets, plus Internet Explorer mode.
Driver management Used to be a standing maintenance tax on Selenium suites.	Not applicable, browsers are managed for you.	Selenium Manager resolves drivers automatically, which removed most of that pain.
Multiple origins, tabs and windows Hosted login, third party checkout, "open in new tab".	One superdomain per test, with cy.origin for cross origin steps. No tab support.	Unrestricted navigation, window handles for tabs and popups.
Stability and waiting
Default waiting behaviour Where most flake originates in either tool.	Commands and assertions retry until a timeout, so waits are rarely written by hand.	Explicit waits are the correct pattern and must be written deliberately. Implicit waits cause more harm than good.
Flake profile in practice The difference between a suite people trust and a suite people rerun.	Lower out of the box, because the retry model is built in.	Depends almost entirely on framework quality. A well built Selenium suite is very stable; a careless one is the source of the reputation.
Test retries	Configurable per run and per test.	Provided by the runner you chose, for example TestNG or pytest plugins.
Scale, CI and cost
Parallel execution The main lever on pipeline duration.	Balanced parallelism through Cypress Cloud, or a self hosted service such as Currents.	Selenium Grid, or any commercial device cloud, distributed by your runner.
Cost model at scale Where the budget conversation actually lands.	CI compute plus per result pricing that grows with runs per day.	CI compute plus grid infrastructure you operate, or device cloud subscriptions.
Cross browser matrix runs	Limited by browser support rather than by mechanics.	Its original purpose. Broad matrices are routine.
Device cloud compatibility Matters when real devices and real Safari versions are contractual.	Supported by some providers, with narrower coverage.	Universally supported. Every provider speaks WebDriver.
Writing and diagnosing tests
Interactive runner	In browser runner with per command DOM snapshots and time travel.	None. You debug through your IDE and logs.
Failure artefacts Determines how long a CI failure takes to explain.	Screenshots and video by default, richer history in Cloud.	Whatever your framework captures. Usually a screenshot and a stack trace.
Network interception Stubbing a slow or unavailable dependency is how you test error states.	cy.intercept, mature and central to the workflow.	WebDriver BiDi is bringing interception and console access, still newer than the Cypress equivalent.
Reporting	Built in, with analytics in Cloud.	Assembled from your runner plus Allure or similar. Flexible, and your job to maintain.
Reach beyond the browser
Native mobile applications Often the deciding factor in organisations that ship an app as well as a site.	Not supported. Web views on mobile viewports only.	Appium extends the same protocol and patterns to iOS and Android.
Component testing	First class for React, Vue, Angular and Svelte.	Out of scope by design.
Desktop and legacy targets	Out of scope.	Adjacent projects cover desktop applications, and Internet Explorer mode still exists for regulated legacy estates.
Organisational fit
Hiring pool	Strong among front end and JavaScript engineers.	The largest pool in QA overall, especially Java and C# automation engineers.
Standards and procurement Regulated buyers often prefer a standard to a product.	A vendor backed open source product.	A W3C standard with no single vendor, which simplifies some approvals.
Longevity risk	Depends on one company sustaining the product.	Two decades old, vendor neutral, embedded in enterprise estates everywhere.

A tick marks the option we would pick on that row alone. Rows without a tick are close enough that the choice should come from elsewhere in the table. Checked August 2026; tool releases move quickly, so verify anything you are about to spend money on.

Pick One

Which one fits your situation

Find the list that describes your team, not the tool with the longest feature table.

Choose Cypress if

The product is a web application, on one origin, with no native app to cover.
The team writes JavaScript or TypeScript already.
You want component tests and journey tests in the same tool.
Automation needs to show value inside a quarter.
Nobody wants to own grid infrastructure.

Choose Selenium if

Safari, or Internet Explorer mode, is part of the supported matrix.
Your automation engineers work in Java, C#, Python or Ruby.
You already run a grid, or a device cloud contract you intend to use.
The same patterns need to extend to native mobile through Appium.
Procurement or regulation prefers a standard over a single vendor product.
You have a mature framework already. A working Selenium suite is an asset, not a legacy problem.

What Changes The Answer

Conditions that reverse the recommendation

A recommendation with no stated limits is a guess. These are the situations where ours does not hold.

Native mobile enters scope

Once iOS and Android apps need coverage, Selenium with Appium keeps one skill set and one set of patterns across web and mobile.

A non JavaScript team owns quality

Cypress asks a Java or C# organisation to maintain a JavaScript codebase. That is a real cost, paid in review quality and staffing.

You are starting from nothing today

Consider Playwright before either. It covers WebKit, offers multi language bindings and free parallelism, which removes most of the reasons this comparison used to be difficult.

Your Selenium suite is already trusted

Rewriting a stable suite spends quarters to reach the coverage you have. Fix the framework instead: better waits, better data setup, better reporting.

In Detail

Where the differences actually bite

The dimensions from the table, with the reasoning that would not fit in a cell.

Comparing a product with a standard

Cypress decides your runner, your assertion style, your reporting and your debugging loop. That is why it is quick to adopt and why it resists being bent into unusual shapes.

Selenium decides only how a browser is driven. Everything a team experiences as "our automation" (waits, page objects, data setup, reporting, parallel strategy) is code somebody at your organisation wrote. That is why Selenium suites vary so wildly in quality, and why "Selenium is flaky" is usually a statement about a framework rather than about Selenium.

The practical consequence: budget framework engineering time if you choose Selenium. Teams that treat it as a library to import, with no design work, produce the brittle suites the tool gets blamed for.

Is Selenium in decline?

New projects overwhelmingly start on Playwright or Cypress, and most new tutorial content targets them. That is a genuine shift in momentum and worth factoring into hiring and training plans.

It is not the same as decline. Selenium underpins WebDriver in every browser, every commercial device cloud speaks it, Appium is built on it, and enterprise regression estates depend on it. It also keeps evolving: Selenium Manager removed driver maintenance, and WebDriver BiDi is closing the network interception and console access gap that modern tools opened.

A fair summary for 2026: Selenium is no longer the default choice for a greenfield web suite, and remains the right choice for breadth, for non JavaScript teams and for anyone whose automation must reach beyond the browser.

Where each one actually flakes

Cypress flake concentrates around the boundaries of its model: cross origin steps, iframes, anything wanting a second tab, and long spec files that accumulate memory pressure. Inside its intended shape it is very stable.

Selenium flake concentrates in waiting code. Implicit waits, fixed sleeps and assertions that fire before the DOM settles produce the timing failures the tool is famous for. Teams that adopt explicit waits everywhere, and never mix them with implicit waits, report stability comparable to modern tools.

In both cases the largest single cause is shared mutable test data. Two tests using the same account, running in parallel, will fail intermittently under any framework in any language.

What a migration is really worth

Moving from Selenium to Cypress is a rewrite, not a port: language, runner, waiting model and reporting all change. Estimate it as new development with a known specification, then ask what coverage improves at the end. Frequently the answer is none, and the actual goal was better authoring speed or better debugging, which can sometimes be bought inside the existing framework for far less.

Moving from Cypress to Selenium is rarer and usually driven by a hard constraint: native mobile, Safari, or a language mandate. When that is the driver, the constraint decides it and the comparison table is a formality.

The strategy we most often recommend to teams with a large Selenium estate: leave it running, put new work in a modern tool, and let the old suite shrink as features are retired. Two suites during a transition is acceptable. Two suites forever is not, so set the retirement date up front.

Before You Commit

Mistakes teams make on this decision

Blaming the tool for framework debt

Most complaints about Selenium describe a suite with sleeps, shared accounts and no reporting. Replacing the tool moves that debt into a new language rather than clearing it.

Ignoring who will maintain it

A JavaScript suite in a Java organisation gets reviewed by people who do not read the language fluently. Coverage decays quietly for reasons that have nothing to do with either tool.

Forgetting Safari until launch

Safari specific defects are common and mostly invisible in Chromium. Decide early whether that coverage is required, because it eliminates one of these options.

Treating Appium as a separate problem

If a native app is on the roadmap, the browser tool choice is really a platform choice. Deciding them separately produces two frameworks, two skill sets and double the maintenance.

Skipping the parallel cost model

A self operated grid costs engineering time; a device cloud and a per result dashboard cost money. Neither is free, and the cheaper option depends on your run frequency, not on the sticker price.

Inherited a flaky Selenium suite?

QAble stabilises existing frameworks as well as building new ones. Often the fix is waits, test data and reporting rather than a rewrite.

Test automation services

Switching Cost

Migrating between the two

Treat it as a rewrite with a known specification. Selectors and expected outcomes carry over as documentation; almost nothing carries over as code. Waits, page objects, data setup, reporting and CI configuration are all rebuilt.

Sequence that works: pick the ten journeys that would hurt most if they broke, implement those in the new tool, run both suites in parallel for a quarter, and compare defect detection and stability rather than opinions. If the new suite does not clearly win on those two numbers, the migration was not the fix you needed.

Do not translate specs one for one. Suites accumulate tests that duplicate lower layer coverage or guard removed features. Migration is the best opportunity you will get to delete them, and the worst possible time to carry them across out of caution.

Questions

Questions people ask before choosing

Is Selenium dead in 2026?

No. It is no longer the default for a new web suite, which is a different claim. WebDriver is the standard every browser implements, every device cloud speaks it, Appium is built on it, and Selenium Manager plus WebDriver BiDi have closed two of its oldest weaknesses. For breadth of browsers and languages it is still the most capable option.

Is Cypress replacing Selenium?

In greenfield web projects at JavaScript shops, often yes, though Playwright has taken most of that momentum. In enterprises with mobile apps, legacy browser requirements or non JavaScript teams, no, and the reasons are structural rather than about preference.

Can Cypress test a native mobile app?

No. It tests web content, including a mobile viewport or a web view. Native iOS and Android automation needs Appium, which is built on the same WebDriver protocol Selenium uses, or a platform specific framework.

Does Selenium have automatic waiting?

Not in the way modern tools do. Explicit waits are the correct pattern and you write them deliberately. Implicit waits look convenient and interact badly with explicit waits, so most experienced teams disable them entirely.

Which one is better for Safari?

Selenium. Safari is a supported target through its own driver, and every device cloud can give you real Safari versions. Cypress WebKit support has remained experimental rather than becoming a coverage guarantee.

Which is better for a large regression suite?

Whichever your team can keep stable. Mechanically, Selenium scales across browsers and machines without licence constraints, while Cypress gives you a faster authoring loop and needs Cloud or an equivalent for balanced parallel runs. At several thousand tests, framework discipline decides the outcome more than the tool does.

Should we consider Playwright instead of both?

Usually yes, if you are choosing today with no existing investment. It offers WebKit coverage, multiple language bindings and free parallelism, which addresses most of the reasons teams used to have to choose between these two.

How We Compared

How this comparison was put together

QAble maintains suites in both. Our Selenium work is mostly enterprise regression estates in Java and C#, often alongside Appium for the mobile app, and our Cypress work is mostly product teams shipping web applications weekly. The rows here are the ones that have actually changed a client decision.

We have tried to be careful about one specific unfairness in most published comparisons: they compare a well configured Cypress project against a badly built Selenium framework and conclude the tool is flaky. A Selenium suite with disciplined explicit waits and clean test data is stable. Where the tool genuinely costs you more, the table says so.

Version specific details were checked in August 2026. Selenium Manager and WebDriver BiDi have changed the picture meaningfully in recent years, so older comparisons you find elsewhere are likely to overstate the gap. If anything here is wrong for your stack, tell us and we will fix it.

Tell us where we are wrong

More comparisons

View all

Sources

Cypress documentation first-party reference for the runner, retries and component testing.
Selenium documentation first-party reference for WebDriver, Grid and language bindings.
W3C WebDriver the specification Selenium implements.