Selenium: The Browser Automation Framework Behind W3C WebDriver

What Selenium automates and who it targets

Selenium automates web browsers. It lets test code open a browser, navigate to a URL, interact with page elements, and assert outcomes, all without human input. The README describes it as "an umbrella project encapsulating a variety of tools and libraries enabling web browser automation" built around the W3C WebDriver specification. That specification defines a platform-neutral, language-neutral HTTP protocol that all major browsers implement natively since the W3C standardized it. The primary audience is software engineers writing automated tests for web applications and QA teams building regression suites. A secondary audience is developers building browser-based scrapers, workflow automation, or accessibility testing tools. Because the underlying protocol is a published standard, Selenium bindings can drive Chrome, Firefox, Safari, and Edge using the same API surface.

The W3C WebDriver specification as the foundation

Unlike earlier automation tools that injected JavaScript directly into pages or relied on browser-specific extensions, Selenium communicates with browsers through the W3C WebDriver HTTP API. Each browser vendor ships a driver binary (ChromeDriver, GeckoDriver, SafariDriver, and so on) that speaks the WebDriver protocol; Selenium bindings send HTTP requests to that driver, which in turn controls the browser process. The README calls Selenium "a platform and language-neutral coding interface compatible with all major web browsers". This layered design means the same test code runs on different browsers by swapping the driver, and it means Selenium is not responsible for browser rendering behaviour, only for issuing commands and reading responses. The trade-off is that each browser driver is a separate release artifact with its own version requirements, which is one of the most common sources of setup friction.

Language bindings available in the repository

The Selenium repository is a monorepo. Its top-level directories include `java/`, `py/`, `javascript/`, `rb/`, `dotnet/`, `go/`, and `rust/`, one directory per supported language binding. The package.json file lists two JavaScript workspaces: `javascript/grid-ui` (the Grid's browser-based management console) and `javascript/selenium-webdriver` (the npm package). The Java bindings are the most mature and are the reference implementation against which new WebDriver specification features are first validated. The Python bindings are distributed on PyPI as `selenium` and are the most commonly used binding for scripting workflows. Each binding is versioned and released independently from the others, though the main repository coordinates major releases. The README states that nightly builds are published from the trunk branch; the most recent stable release at the time of the last push was Selenium 4.49.0.

How to install Selenium in Python

End users do not build from source. The Python binding installs from PyPI:

pip install selenium

After installing, the script also needs a browser driver. ChromeDriver is the most common choice. Selenium 4 introduced the Selenium Manager tool, which the README's User Manual documents as a way to manage driver binaries automatically. The README says that people looking to get started should consult the User Manual at selenium.dev/documentation/ rather than the repository README, which is oriented toward contributors. The JavaScript binding installs from npm:

npm install selenium-webdriver

Both packages are pinned to the release cadence of the monorepo. Mismatching the binding version with the browser driver version is the most common cause of incompatibility: a test that passed against Chrome 124 with a matching ChromeDriver may fail after a browser auto-update if the driver binary is not also updated.

Building Selenium from source for contributors

The repository builds with Bazel, using Bazelisk as a version manager wrapper. The README requires Java JDK 17 or higher, with the JAVA_HOME environment variable pointing to the JDK rather than the JRE. On macOS, the build also requires Xcode command-line tools. The README provides three alternatives to a local dev environment setup: GitPod (a browser-based ready-to-use environment launched directly from the repository), a Dev Container configuration under `.devcontainer/devcontainer.json` compatible with VS Code and IntelliJ IDEA, and a Dockerfile under `scripts/dev-image/`. For developers working across multiple git worktrees, the README recommends pointing Bazel to user-level disk caches with entries in `~/.bazelrc` to avoid re-downloading dependencies per worktree. Windows contributors face the highest setup cost: the README documents manual registry edits for long path support and MSYS2 installation for Unix-compatible shell commands, or an automated PowerShell script that handles the entire environment from scratch.

Selenium Grid and the javascript/grid-ui workspace

The `javascript/grid-ui` workspace in package.json is the React-based web console for Selenium Grid, the component that distributes tests across multiple browser nodes. Grid allows a test suite to run in parallel across machines, which reduces wall-clock time for large regression suites. The project structure separates the Grid UI from the Node.js binding (`javascript/selenium-webdriver`), making them independently buildable. The Grid server itself is implemented in Java and is distributed as part of the Java package. Teams running a Grid deployment manage browser nodes and their associated driver binaries on each node machine; the Grid console shows node health, session counts, and queue depth. The README does not document Grid configuration options in detail; those are in the User Manual at selenium.dev/documentation/.

Limitations and when Selenium is not the right tool

Selenium's main limitation is setup overhead. Every machine that runs tests needs the right browser driver binary matching the installed browser version. Parallel test runs require either Selenium Grid or a hosted browser service. The HTTP protocol between the binding and the driver adds latency compared to tools that run in-process with the browser. The README is explicitly for developers contributing to Selenium, not for end users, which signals that the project prioritises correctness and standards compliance over getting-started ease. Playwright, a Microsoft-maintained browser automation library, takes a different approach: it ships bundled browser binaries and its own browser control protocol, removing the driver versioning problem at the cost of using non-standard browsers. Playwright supports JavaScript, Python, and .NET but not Java or Ruby as of its core API; teams with existing Java WebDriver tests have no direct migration path.

Maintenance, licence, and the Apache-2.0 grant

Selenium is released under the Apache-2.0 licence, which allows use in commercial products and distribution without requiring source disclosure. The repository's default branch is `trunk` and is actively maintained by volunteer contributors. Nightly builds publish from the trunk branch. The last push was on 2026-09-27 and Selenium 4.49.0 was released on 2026-09-09. The version series continues a trajectory that reached Selenium 4 after years on the older 3.x line. The Apache licence's patent grant clause is relevant for enterprise legal review: it grants a licence to any patents that contributors hold that are necessary to use the software, which is broader than the MIT licence. The project has no paid commercial offering from the core team; the User Manual and documentation are maintained at selenium.dev alongside the codebase.

Editorial conclusion

Selenium is the right choice for teams that need a standards-based browser automation layer across multiple programming languages, or that already have Java or Python test suites they cannot migrate. It is a poor fit for teams starting fresh who need a tighter feedback loop: the setup overhead (browser drivers, versioned bindings, Bazel for source builds) is real. Before adopting it, confirm that your language binding's version matches the browser driver version, and decide whether you will use the prebuilt npm, pip, or Maven artifacts or build from the repository. The last push was on 2026-09-27 and Selenium 4.49.0 was released on 2026-09-09, with nightly builds available.

Frequently asked questions

Official sources

1. Official documentation
2. Official README
3. Project repository
4. Release notes