What Is Selenium WebDriver? The Selenium Ecosystem Explained

If you have spent any time around browser automation or web-application testing, the name Selenium has almost certainly come up. The trouble is that "Selenium" isn't a single thing — it's an umbrella over a family of tools, protocols, and historical projects, each with its own name. For a newcomer, the vocabulary alone (Core, RC, WebDriver, Grid, IDE, Selenese…) can be genuinely disorienting.

This guide untangles that vocabulary. By the end you should be able to say, with confidence, what each piece is, which pieces still matter in 2026, and where Selenium fits relative to newer automation tools.

What Is Selenium?

Selenium is an open-source toolkit for automating web browsers. Its original and still-primary use case is automated testing of web applications — driving a real browser through a scripted sequence of clicks, form fills, navigations, and assertions to verify that an application behaves correctly.

A few defining characteristics:

• Multi-language. You can write Selenium scripts in the officially supported bindings — Java, Python, C#/.NET, JavaScript, and Ruby — and several community bindings exist beyond those.
• Cross-platform. It runs on Windows, macOS, and Linux.
• Cross-browser. It drives Chrome, Firefox, Edge, Safari, and others through their respective drivers.
• Free and open source. Selenium is released under the Apache License 2.0, so you can use it commercially at no cost. The project is stewarded by the Software Freedom Conservancy, with source code on GitHub.

The official home for everything Selenium is selenium.dev (the old seleniumhq.org address now redirects there). Documentation lives at selenium.dev/documentation, and downloads at selenium.dev/downloads.

The Terminology, Decoded

Below are the names you'll keep bumping into. I've flagged clearly which ones are still relevant and which are now purely historical, because a lot of older tutorials still talk about deprecated components as if they were current.

Selenium WebDriver — the core of everything today

WebDriver is the heart of modern Selenium. Instead of injecting JavaScript into a page to fake user actions (the old approach — see Selenium Core below), WebDriver talks to each browser through that browser's native automation interface. Browser vendors ship and maintain their own drivers — for example chromedriver for Chrome and geckodriver for Firefox — and WebDriver speaks to them over a standard wire protocol.

This native approach is more robust and more faithful to real user behavior, and WebDriver exposes a clean, object-oriented API rather than the dictionary-style command set the old tools used.

Crucially, WebDriver is now a web standard. The W3C WebDriver specification became an official W3C Recommendation in 2018, which means browser makers implement a common, interoperable protocol rather than each driver behaving slightly differently. Selenium 4 dropped the old legacy protocol entirely and uses the W3C standard by default.

Selenium Grid — run tests in parallel, everywhere

Selenium Grid lets you distribute test execution across multiple machines and browsers simultaneously. If you need to run the same suite against Chrome, Firefox, and Edge on different operating systems at once, Grid coordinates that fan-out. Modern Grid scales from a single machine to large Docker- and Kubernetes-based clusters, which makes it a backbone for continuous-integration pipelines.

Selenium IDE — record and play back, no coding required

Selenium IDE is a record-and-playback tool. It captures your interactions in the browser and turns them into a replayable test, and it can export those steps as code in several languages. Historically it was a Firefox-only add-on; today it's a cross-browser extension available for Chrome, Firefox, and Edge. It's a great way to learn how Selenium thinks, but recorded scripts behave differently from code-driven WebDriver tests, so it's best treated as a starting point rather than a production solution.

Selenese — the command vocabulary

Selenese is the name for the set of Selenium commands (open a URL, click an element, type text, assert a value, and so on). A sequence of these commands forms a test script. You'll mostly encounter the term in the context of the IDE and the older tools.

Selenium Core — historical

Selenium Core was the original engine: a bundle of JavaScript that was injected directly into the web page and executed a list of commands to imitate a user. This is the technique WebDriver deliberately moved away from, and Core is no longer part of the project.

Selenium RC (Remote Control / "Selenium 1") — deprecated and removed

Selenium RC existed to work around the browser's "same-origin" restriction. It ran a server that received Selenium Core commands over HTTP and proxied them into the browser, which also opened the door to writing tests in many languages. RC was officially deprecated in favor of WebDriver years ago and has been removed from current Selenium. If a tutorial tells you to use Selenium RC, it's out of date.

A Short History

A quick timeline helps explain why so many of these names exist:

• 2004 — Jason Huggins creates a JavaScript-based testing tool at ThoughtWorks. It becomes Selenium Core. To get around the same-origin policy and enable multiple language bindings, Selenium Remote Control (Selenium 1) follows.
• 2006–2007 — Simon Stewart begins work on a separate, more architecturally sound automation tool called WebDriver.
• 2009 — The two projects merge. WebDriver + the Selenium project become Selenium 2.0 (Selenium WebDriver).
• 2016 — Selenium 3 ships, beginning the move toward the W3C protocol and retiring the original Core/RC engine.
• 2018 — The W3C WebDriver specification reaches Recommendation status, standardizing browser automation across vendors.
• 2021 — Selenium 4 is released (October 13, 2021), fully W3C-compliant by default and adding features like relative locators, improved Grid, and Chrome DevTools Protocol integration.
• 2022 onward — Selenium 4.x continues active development, layering in WebDriver BiDi, a newer bidirectional protocol for richer, event-driven browser control.

Where Should You Start?

For a practical learning path in 2026:

1. Play with Selenium IDE to get an intuitive feel for Selenium commands and see automation happen live. Treat it as a sandbox, not a destination.
2. Move to Selenium WebDriver in the language you're most comfortable with. This is the real tool you'll build on. Start from the official WebDriver documentation.
3. Add Selenium Grid once you need to run tests in parallel or across multiple browser/OS combinations.

Install the language binding you want straight from its package manager — for example, selenium on PyPI for Python, selenium-webdriver on npm for JavaScript, or the Selenium artifacts on Maven Central for Java. Modern Selenium also bundles Selenium Manager, which automatically downloads and matches the correct browser driver for you, removing one of the most common setup headaches.

A Reality Check: Selenium and Anti-Bot Detection

There's an important caveat that older introductions to Selenium simply don't mention, because it wasn't a concern back then. Selenium was built for testing your own applications — not for scraping sites that don't want to be automated — and modern anti-bot systems detect stock Selenium almost instantly.

Services like Cloudflare and DataDome look for a long list of tell-tale automation signals, and a default Selenium session leaks several of them:

• The navigator.webdriver flag. Standard WebDriver sets this property to true, which is effectively a flashing sign that announces "I am automated."
• Driver-specific DOM artifacts. Variables such as the $cdc_… properties injected by ChromeDriver are easy to fingerprint.
• Chrome DevTools Protocol (CDP) signatures and a HeadlessChrome user-agent string when running headless.
• TLS and HTTP/2 fingerprints that don't match the browser version the session claims to be.
• Behavioral and environmental checks — mouse movement, timing, canvas fingerprinting, missing browser-runtime properties — that a scripted session struggles to reproduce convincingly.

Because of this, a plain Selenium scraper frequently runs into "Checking your browser…" interstitials, CAPTCHAs, 403 responses, or endless redirect loops on protected sites. A whole cottage industry of stealth patches has grown up to paper over these leaks — undetected-chromedriver (now deprecated and increasingly easy to detect), selenium-stealth, SeleniumBase's UC mode, and newer projects like nodriver — but it's an ongoing cat-and-mouse game, and none of them is a permanent guarantee.

The honest takeaways:

• For testing your own web apps — Selenium's intended purpose — none of this matters. It remains an excellent, standards-based, free choice.
• For scraping protected third-party sites, expect to be detected. You'll need stealth tooling, residential proxies, and constant maintenance, and you should weigh the legal and terms-of-service implications before bypassing a site's protections.
• If your goal is automation rather than testing specifically, it's worth comparing Selenium with newer frameworks like Playwright and Puppeteer, which many teams find more ergonomic for modern, JavaScript-heavy pages — though they expose many of the same automation fingerprints and face the same detection challenges.

In Summary

Selenium is a mature, standardized, genuinely useful automation framework — and for its original mission of cross-browser application testing, it's still a first-rate, free choice. Just go in with clear eyes: the modern web actively defends against automation, and "vanilla" Selenium wears its automation on its sleeve.

Start exploring at selenium.dev.