Before Selenium, browser testing was a painful, manual process. QA engineers clicked through websites by hand, checking the same flows over and over. Commercial automation tools existed, but they were expensive, proprietary, and limited in browser support.

Then, in 2004, a developer at ThoughtWorks got frustrated with testing an internal time-tracking app. His solution would eventually become a W3C standard and the foundation for modern browser automation.

The Origin Story (2004)

Jason Huggins was a tech lead at ThoughtWorks in Chicago, working on an internal time and expense application. As a consulting firm, accurate billing was critical, so the app had to work perfectly. Testing it manually was tedious and error-prone.

Huggins built a JavaScript test runner he called "JavaScriptTestRunner." It could drive a browser automatically, clicking buttons and verifying results. When he demoed it to colleagues, they immediately saw its potential beyond the time-tracking app.

By the end of 2004, ThoughtWorks open-sourced the tool. But it needed a name.

Why "Selenium"?

The dominant commercial testing tool at the time was Mercury QuickTest Professional. According to Sauce Labs' account of Selenium's history, testing legend Bret Pettichord jokingly told Huggins that if he kept working on this automation project, it could be a "Mercury Killer." Huggins, searching for a witty response, emailed back making the connection: selenium supplements serve as a cure for mercury poisoning.

The joke stuck. The name was memorable, and the chemistry reference to curing the competition proved prophetic.

The Evolution: From Hack to Framework

Selenium didn't arrive fully formed. It evolved through several distinct phases, each solving problems the previous version couldn't handle. The project's growth was driven by a community of contributors at ThoughtWorks and beyond.

Selenium Core (2004)

The original version ran JavaScript directly in the browser. It worked, but had a critical limitation: the same-origin policy. JavaScript could only interact with pages from the same domain as the test runner. Testing across domains was impossible.

Selenium RC (Remote Control, 2005)

Paul Hammant, another ThoughtWorks developer, had been advocating for open-sourcing Selenium and developing a "driven" mode to work around same-origin limitations. The result was Selenium RC: a proxy server that sat between the browser and the test code, injecting JavaScript and relaying commands.

RC was groundbreaking. It let developers write tests in Java, Python, Ruby, and other languages, not just JavaScript. But the proxy architecture was fragile. Tests were slow and prone to timing issues.

Selenium IDE (2006)

Shinya Kasatani in Japan had a different idea. He wrapped Selenium Core into a Firefox extension that could record user actions and play them back. Non-programmers could now create automated tests by simply using the browser.

Selenium IDE democratized test automation. QA teams who couldn't write code could still create regression tests. It's still available today as a Chrome and Firefox extension.

Selenium Grid (2008)

Philippe Hanrigou at ThoughtWorks tackled a different problem: scale. Running tests sequentially was slow. Grid introduced a hub-and-node architecture where tests could run in parallel across multiple machines, browsers, and operating systems.

Grid made continuous integration practical. A test suite that took hours could run in minutes by distributing tests across a cluster.

The WebDriver Revolution (2009–2011)

While Selenium evolved, Simon Stewart (also at ThoughtWorks, later at Google) was building something different: WebDriver. Instead of injecting JavaScript into browsers, WebDriver communicated directly with browser-specific drivers.

Each browser had its own driver (ChromeDriver, GeckoDriver, etc.) that spoke the browser's native automation protocol. This was faster, more reliable, and could do things JavaScript injection couldn't, like handling file uploads and native dialogs.

In 2009, at the Google Test Automation Conference, the Selenium and WebDriver teams decided to merge. The result was Selenium 2.0 (released July 2011), combining Selenium's ecosystem with WebDriver's architecture.

Becoming a Standard (2018)

The most significant milestone came on June 5, 2018, when the WebDriver protocol became a W3C Recommendation. Simon Stewart and David Burns (Mozilla) serve as the specification editors, working within the W3C's Browser Testing and Tools Working Group.

This was huge. Browser vendors now had to implement WebDriver. Chrome, Firefox, Safari, and Edge all ship with built-in WebDriver support. The API that started as a ThoughtWorks side project is now part of the web platform itself.

Selenium 4 (2021)

Selenium 4 fully adopted the W3C WebDriver protocol, dropping the old JSON Wire Protocol. It also introduced:

  • Relative locators: Find elements "near", "above", or "below" other elements
  • New Grid architecture: Docker-native, with better observability
  • Chrome DevTools Protocol support: Network interception, performance metrics
  • WebDriver BiDi: Bidirectional communication for real-time events

Selenium Today: Still Relevant?

With newer tools like Playwright and Puppeteer gaining popularity, where does Selenium fit in?

Selenium maintains advantages in several areas: it supports Java, Python, C#, Ruby, and JavaScript, letting teams use their existing stack. It remains the only option for Internet Explorer and legacy browsers. The W3C standard guarantees ongoing browser vendor support. And after two decades, the ecosystem of documentation, community answers, and tooling is unmatched.

Newer tools offer different tradeoffs. Playwright provides auto-waiting, better debugging, and native mobile emulation. Cypress runs tests in-browser with time-travel debugging. Puppeteer offers direct Chrome DevTools Protocol access with a lighter footprint.

In practice, JavaScript/TypeScript teams starting new projects often choose Playwright or Cypress. Enterprise teams with large existing Selenium test suites typically stay with Selenium 4, which is actively maintained with long-term W3C backing. Multi-language teams or those needing legacy browser support generally find Selenium remains the practical choice.

The Legacy

Selenium's greatest contribution isn't the tool itself. It's the standard. Before Selenium, browser automation was proprietary, expensive, and fragmented. Tests were tied to specific tools, cross-browser testing required different products for each browser, and there was no common protocol.

Selenium changed that. It made browser automation free and open source, enabled tests in any major programming language, and unified cross-browser testing under one API. When WebDriver became a W3C standard, browser vendors committed to implementing it. The API that started as a ThoughtWorks side project is now part of the web platform.

Every modern browser automation tool builds on concepts Selenium pioneered. When you use page.click() in Playwright or cy.get() in Cypress, you're using patterns that trace back to Jason Huggins' JavaScript test runner in 2004. The API has evolved, but the fundamental idea of programmatically driving a browser to simulate user actions came from Selenium.

Further Reading