What Is Selenium RC? A Guide to the Legacy Testing Tool
Selenium RC was Selenium 1, a legacy browser testing tool. Learn what replaced it, how its architecture worked, and how to move an existing suite to WebDriver.
Selenium RC means Selenium Remote Control. It was Selenium 1, the project’s original browser automation tool. Selenium 2 introduced WebDriver, Selenium 3 removed the original RC implementation, and Selenium 4 implements the W3C WebDriver specification. RC documentation remains useful for understanding old projects, but WebDriver is the practical choice for new tests and ongoing maintenance.
What does RC mean in Selenium?
RC stands for Remote Control. Selenium RC used a client/server arrangement: test code in a language binding communicated with the Selenium RC server, which mediated browser automation using Selenium Core, a JavaScript framework running in the browser. This is a high-level description; implementation details varied across the historical stack.
WebDriver follows a different model. It uses browser automation APIs provided by browser vendors rather than Selenium Core. The current Selenium overview points people starting browser automation to WebDriver APIs.
How Selenium RC evolved into WebDriver
- Selenium 1 / RC: The original Selenium version, built around Selenium Core and the RC server.
- Selenium 2: A rewrite of Selenium 1 that introduced WebDriver code. It also provided a WebDriver-backed implementation of the older Selenium API as a transition path.
- Selenium 3: The original Selenium Core implementation was removed. RC interfaces moved to a legacy package, while WebDriver became the actively supported API direction in the project’s announcement. The project discouraged using the legacy path unless necessary.
- Selenium 4: The current generation described by Selenium as implementing the W3C WebDriver specification.
In the Selenium 3 announcement, project author Simon Stewart wrote: “The WebDriver APIs are now the only APIs actively supported by the Selenium project.” That describes the project’s position at the time of the Selenium 3 announcement, rather than serving as a timeless quotation about every later policy.
The official Selenium legacy index says its legacy documentation is retained for historical reasons and is not an incentive to use deprecated components. See the Selenium legacy documentation, the Selenium 2 announcement, the Selenium 3 announcement, and the current Selenium documentation.
Is Selenium RC deprecated?
For practical purposes, treat Selenium RC as legacy. Selenium 3 removed the original implementation and retained legacy interfaces for compatibility; it did not make RC the recommended way to start a browser automation project. Selenium’s current overview directs new browser automation work to WebDriver.
Historical downloads and compatibility code do not establish that an old RC setup will work with a particular current browser, driver, language binding, or operating system. If a suite still runs, preserve its environment and results while you plan the move. Avoid starting new test code with RC interfaces.
Selenium RC vs WebDriver
| Area | Selenium RC | WebDriver |
|---|---|---|
| Role | Selenium 1’s original automation API | The API direction introduced in Selenium 2 and used by current Selenium |
| Automation model | Client talks to an RC server; Selenium Core runs in the browser | Automation through browser-provided APIs |
| Project status | Legacy interfaces and historical material | Current direction for browser automation |
| Existing code | May run in a constrained legacy environment | Requires validating setup, locators, and behavior during migration |
| New tests | Not a suitable starting point | Use current WebDriver APIs |
This is a comparison of the documented project direction, not a claim that every team’s migration has the same effort or outcome.
How to migrate Selenium RC tests to WebDriver
Migration need not be an all-at-once rewrite. The historical migration guide describes changing how tests obtain their Selenium instance, then moving test code incrementally. Its Java example uses WebDriverBackedSelenium as a compatibility bridge. Treat that mechanism as a historical transition aid, not a pattern for greenfield tests.
- Record a baseline. Get the existing suite running with its current dependencies and record the expected outcomes. The migration guide recommends stabilizing tests before migration.
- Pin down the environment. Record the language binding, Selenium version, browser, driver, operating system, and any server configuration needed to reproduce current results.
- Choose a small representative group. Migrate a few tests that cover common navigation, form interaction, and locator patterns. Compare results with the baseline.
- Change test setup first. Move creation and lifecycle management of the automation object to WebDriver. Where an existing Java suite needs a temporary bridge, consult the matching legacy migration documentation and verify the exact binding and version.
- Replace legacy API calls incrementally. Move test actions and assertions to WebDriver APIs in manageable groups, preserving a clear link between old and migrated tests.
- Audit locators and Core dependencies. XPath or CSS expressions accepted by Selenium 1 may behave differently with browser-native WebDriver locators. Code that relied on Selenium Core facilities such as Browserbot cannot be carried across unchanged.
- Run and review the suite after each increment. Investigate differences as behavior changes, rather than assuming the new API is a drop-in replacement.
- Remove the compatibility layer when no longer needed. Keep the transition bridge only as long as the remaining old code requires it.
The migration guide is historical documentation, and the detail available for it is limited. Check the documentation for the exact language binding and versions in your project before applying a compatibility example.
Common migration problems and fixes
| Symptom | Likely cause | What to check |
|---|---|---|
| A locator that worked under RC no longer finds an element | The expression may have relied on Selenium Core behavior or be interpreted differently by WebDriver and the browser | Inspect the locator against the current page DOM and the WebDriver locator rules; replace it with a locator supported by the binding and browser |
| Code referencing Browserbot or other Core facilities fails | WebDriver is not based on Selenium Core, so those facilities are unavailable | Rewrite the test around WebDriver’s supported browser interaction APIs instead of porting the Core dependency |
| The old suite stops running before migration begins | The legacy dependency or surrounding browser stack may no longer match the environment | Restore and record a reproducible baseline first; check the project’s exact dependency and browser setup before changing test logic |
| Some migrated tests pass and others differ | The implementation technology changed, and individual tests may depend on old locator or Core behavior | Compare failures with the baseline, isolate affected patterns, and migrate in smaller increments |
| A compatibility wrapper does not compile or behave as an example suggests | The example may target an old Java package or version and is not necessarily valid for the project’s binding | Match the migration example to the exact Selenium release and binding; keep the wrapper temporary |
When a screenshot API helps alongside browser tests
Browser automation and page screenshots answer different questions. WebDriver is for interacting with and testing a browser. A screenshot API is useful when a test or workflow needs a rendered image or PDF of a URL without maintaining its own browser capture setup. ScreenshotNeo is a website screenshot API and MCP server by Yorker Media; it is an adjacent tool, not a replacement for Selenium WebDriver.
Or skip the browser setup
Make one GET request to capture a page as an image or PDF. See the ScreenshotNeo API documentation for request options.
curl -G "https://api.screenshotneo.com/v1/shot" -d access_key=YOUR_API_KEY --data-urlencode url=https://stripe.com -o shot.webpimport requests
r = requests.get("https://api.screenshotneo.com/v1/shot", params={"access_key": "YOUR_API_KEY", "url": "https://stripe.com"}, timeout=90)
open("shot.webp", "wb").write(r.content)const q = new URLSearchParams({ access_key: 'YOUR_API_KEY', url: 'https://stripe.com' });
const res = await fetch(`https://api.screenshotneo.com/v1/shot?${q}`);ScreenshotNeo accepts cookie and consent banners and removes more than 60 known consent platforms, newsletter popups, and chat widgets before capture; each step can be turned off. Bot checks, blank pages, timeouts, failed loads, and cache hits cost nothing, with response headers indicating the page verdict and billing status. Its MCP server provides take_screenshot, get_page_info, and capture_pdf tools for AI agents. The free plan includes 1,000 screenshots a month with no card; paid plans start at $5 for 3,000 shots. Sign up for 1,000 free screenshots a month, with no card required.
Performance, reliability, and cost considerations
- Performance: The sources do not provide a benchmark comparing RC with WebDriver. Avoid assuming a particular speedup from migration. First identify whether suite time comes from browser startup, navigation, waits, or test design.
- Reliability: RC’s age and different automation model make environment reproduction important. Preserve the working baseline, migrate in small groups, and validate locator behavior and any Selenium Core dependencies.
- Cost: Selenium is software; the cited documentation does not specify a Selenium license charge. Operational costs can include the machines, browser infrastructure, and engineering time needed to maintain a test suite. The actual cost depends on the team’s setup.
Frequently asked questions
Can Selenium RC still be used to learn browser automation?
It can help explain Selenium’s history, but new learners should start with current WebDriver documentation because that is the direction Selenium recommends for browser automation.
Was Selenium 2 just Selenium RC with a new name?
No. The project describes Selenium 2 as a rewrite of Selenium 1 implemented with WebDriver code, while also providing a WebDriver-backed version of the old API for transition.
Does every RC test need to be rewritten at once?
No. The migration guide describes piecemeal migration. A team can move a suite incrementally, validating each group against its baseline.
Will old Selenium RC locators work unchanged?
Do not assume so. The migration guide calls out possible differences in XPath and CSS locator handling, and code that depends on Selenium Core internals needs a separate migration plan.
