What to Expect from Selenium 3: Changes for Browser Automation

Selenium 3 was generally a low-friction upgrade for teams using WebDriver, but it was a significant architectural cleanup: Selenium removed the original Selenium Core implementation and moved Selenium RC APIs into a legacy compatibility package backed by WebDriver. Most WebDriver API code could continue with little change; Selenium RC suites and Grid deployments deserved a closer review.

Selenium 3.0 was announced on October 13, 2016, after Selenium 2.53.1. This guide explains what changed at the time, who needed to act, and how to interpret that release today. Selenium 3 is historical guidance: current setup and migration instructions belong to Selenium 4 documentation.

1. What changed in Selenium 3?

The major-version number marked removal of Selenium Core, the JavaScript implementation associated with the original Selenium RC approach. The Selenium project retained RC interfaces in a legacy package, but their implementation was now backed by WebDriver. That meant an RC test could behave differently even when its calls still compiled.

For ordinary WebDriver API users, the project described Selenium 3 as a drop-in replacement and called out bug fixes and stability improvements. That was a general expectation, not a guarantee for every setup: Grid configuration and RC usage were specific areas to inspect. See the Selenium 3.0 release announcement.

2. Who needed to make changes?

Use case	Expected impact in the Selenium 3 era	What to check
WebDriver tests on a local browser	Usually low; public WebDriver APIs were described as unchanged from the last 2.x release.	Run the suite against the new binding and browser driver versions used by your environment.
Selenium Grid	Often a simple server or dependency update, but some JSON configuration and command-line parameters changed.	Review node and hub configuration, startup arguments, and the way capabilities are passed.
Selenium RC APIs	Highest migration risk: the old Core implementation was removed and the retained APIs used a WebDriver-backed implementation.	Identify RC-specific dependencies and behavior assumptions; migrate to WebDriver where practical.
Firefox 48 and later in 2016	Required Mozilla’s geckodriver. This was a Firefox-side change and applied to Selenium 2 as well as Selenium 3.	Install and configure geckodriver for the Firefox version and Selenium binding in use.

The October 4 preview said public WebDriver APIs had not changed from the final 2.x release and that a typical Grid installation could often switch to the new JAR or Maven dependency. The final announcement qualified the Grid story by noting configuration and command-line changes. Treat Grid upgrades as simple only after checking the exact launch and configuration surface. See the Selenium 3 preview.

3. Selenium RC and the legacy package

Selenium RC users were the group most likely to encounter functional differences. The old JavaScript Selenium Core was no longer the engine behind RC. The legacy interfaces remained available through an alternative WebDriver-backed implementation, so Selenium 3 did not make every RC-style test impossible, but compatibility did not mean identical behavior.

Find RC imports, API calls, and the dependency that supplies them.
Separate RC suites from WebDriver suites so failures are easier to localize.
Run representative tests against the upgraded stack and compare browser interactions, waits, and session setup.
For Java projects that genuinely needed the old APIs, the project pointed to the selenium-leg-rc dependency. It strongly discouraged using that compatibility package unless necessary.
Plan migration toward WebDriver APIs when maintaining the suite is feasible.

Do not assume every RC test fails, or that a successful compile proves behavior is unchanged. The implementation beneath the API changed, so validate the tests that depend on RC semantics.

4. Firefox 48+, geckodriver, and the release-era caveat

Firefox 48 changed browser internals. Mozilla’s community Firefox driver no longer worked with those releases, and Selenium users were directed to geckodriver, a separate executable in the same broad role as ChromeDriver. The Selenium project explicitly said this requirement applied to Selenium 2 users too. It was not a new Selenium 3 API rule.

At the time, Selenium described geckodriver as alpha software built around an evolving W3C standard. That is release-era context only, not a description of its current maturity. For current installation and compatibility details, check the relevant driver documentation and Selenium’s live downloads page.

5. Protocol support: Selenium 3 was transitional

Selenium 3 supported both the legacy JSON Wire Protocol and the W3C WebDriver protocol while the standard was still developing. Selenium’s upgrade guide places W3C level 1 compliant code around Selenium 3.11, so it is inaccurate to describe all Selenium 3 releases as W3C-only.

During the transition, a session handshake could include capabilities in both formats; the protocol returned by the remote end determined how the session continued. Selenium 4 later removed legacy protocol support. This distinction matters when reading old client code or diagnosing a historical Selenium 3 deployment.

For a Selenium 4 migration, the official guide highlights Capabilities and Actions as areas to review. Standard capability names include browserName, browserVersion, platformName, acceptInsecureCerts, pageLoadStrategy, proxy, timeouts, and unhandledPromptBehavior. The older version and platform names are replaced by browserVersion and platformName; vendor-specific capabilities need a vendor prefix. These are Selenium 4 migration notes, not changes introduced by Selenium 3.0. Consult the official Selenium 4 upgrade guide and legacy protocol explanation.

6. A practical Selenium 3 upgrade checklist

Record the current Selenium binding, browser versions, drivers, and Grid startup configuration.
Classify tests as WebDriver or Selenium RC; locate legacy imports and dependencies.
Upgrade the binding and run a small local WebDriver smoke suite first.
If using Grid, compare JSON configuration and command-line options with the version being deployed.
If running Firefox 48 or later in the release era, configure geckodriver even if the client still uses Selenium 2.
Run RC tests separately and investigate behavior differences rather than assuming API compatibility means implementation parity.
For any present-day deployment, use Selenium 4 setup guidance and verify current browser and driver requirements on their official pages.

7. Troubleshooting common migration problems

Symptom	Likely cause	Fix
Firefox session fails to start or reports a missing driver	In the Selenium 3 release era, Firefox 48+ required geckodriver; the older built-in/community driver path no longer applied.	Install geckodriver and make it available to the process or configure its executable path. Check current official driver guidance for modern versions.
Grid hub or node rejects startup arguments or configuration	Grid JSON fields or command-line parameters changed between versions.	Compare the configuration and launch command against documentation for the exact Grid release; update obsolete fields and flags.
RC tests compile but behave differently	The legacy API is backed by WebDriver rather than the removed Selenium Core implementation.	Isolate the failing RC flow, inspect assumptions about timing and browser interaction, and migrate the affected test to WebDriver where possible.
Remote session rejects capabilities	Client and remote end may be using different protocol expectations or capability names, especially during later Selenium 4 migration.	For Selenium 3-era systems, account for dual JSON Wire/W3C support; for Selenium 4, follow the W3C capability names and vendor-prefix rules in the upgrade guide.
It is unclear whether a failure is an API break	Browser, driver, Grid, and binding changes may have landed together.	Change one layer at a time and reproduce with a small WebDriver smoke test before attributing the issue to the Selenium API.

8. Then versus now

Then: Selenium 3 arrived in 2016 as a comparatively smooth upgrade for WebDriver users, removed Selenium Core, retained RC through a legacy implementation, and operated during the JSON Wire to W3C transition.

Now: Selenium 3 is a historical release. Selenium’s downloads page currently lists Selenium 4.x; consult it at publication and before installing because version information changes. Current WebDriver and BiDi documentation describe modern capabilities, but BiDi is not a Selenium 3 feature. See the current WebDriver documentation and WebDriver BiDi documentation.

9. Automating a browser versus capturing a page

Selenium is useful when a test must interact with a browser: click controls, submit forms, inspect state, or verify a workflow. If the task is to capture a page as an image or PDF, a screenshot API can avoid maintaining browser and driver setup for that capture step. ScreenshotNeo is a website screenshot API and MCP server by Yorker Media. Its API accepts one GET request with a URL and returns a PNG, JPEG, WebP, or PDF. See the ScreenshotNeo API documentation.

For an AI agent workflow, its MCP server provides take_screenshot, get_page_info, and capture_pdf tools for Claude, Cursor, and other MCP clients.

10. Or skip the browser setup

For a screenshot without configuring Selenium and a browser driver, make one request:

curl -G "https://api.screenshotneo.com/v1/shot" -d access_key=YOUR_API_KEY --data-urlencode url=https://stripe.com -o shot.webp

Python:

import requests

r = requests.get(
    "https://api.screenshotneo.com/v1/shot",
    params={"access_key": "YOUR_API_KEY", "url": "https://stripe.com"},
    timeout=90,
)
r.raise_for_status()
open("shot.webp", "wb").write(r.content)

Node.js:

const q = new URLSearchParams({ access_key: 'YOUR_API_KEY', url: 'https://stripe.com' });
const res = await fetch(`https://api.screenshotneo.com/v1/shot?${q}`);
if (!res.ok) throw new Error(`Screenshot request failed: ${res.status}`);
await import('node:fs/promises').then(fs => fs.writeFile('shot.webp', Buffer.from(await res.arrayBuffer())));

Cookie banners, newsletter popups, and chat widgets are removed before the shot, and each cleanup step can be disabled. Bot checks, blank pages, timeouts, failed loads, and cache hits are not billed; response headers report the page verdict and billing status. The MCP server lets AI agents take screenshots. The free plan includes 1,000 screenshots a month with no card; paid plans start at $5 for 3,000 shots. Create a free ScreenshotNeo account.

11. Performance, reliability, and cost considerations

Selenium performance depends on the browser, driver, page, network, and whether sessions run locally or through Grid. Reuse a managed browser session where the test design allows it, avoid unnecessary waits, and use explicit readiness conditions rather than arbitrary long sleeps. A Grid adds remote communication and configuration to the path, so diagnose browser, node, and hub failures separately.

Reliability work should include pinning compatible binding and browser-driver versions, keeping browser and driver updates coordinated, and retaining a small smoke suite that can distinguish infrastructure failure from application failure. For historical Selenium 3 environments, avoid applying modern protocol assumptions without checking the client and remote-end versions.

Selenium itself is software, but running it has infrastructure costs: compute for browser sessions, Grid capacity, maintenance, and engineering time to keep browser drivers aligned. A screenshot API has a different usage model. ScreenshotNeo offers 1,000 free shots monthly, then plans of $5 for 3,000, $15 for 15,000, $39 for 60,000, $99 for 250,000, and $249 for 1,000,000; yearly billing gives two months free, and every feature is on every plan. Choose based on whether you need interactive browser tests or page captures.

12. FAQ

Did Selenium 3 break WebDriver tests?

The project expected most WebDriver API users to see a smooth upgrade, but environments can still differ. Grid settings and Selenium RC behavior needed particular attention.

Did Selenium 3 remove Selenium RC?

It removed the original Selenium Core implementation. RC APIs remained in a legacy package with a WebDriver-backed implementation.

Was geckodriver required only with Selenium 3?

No. The Firefox 48-era driver change applied to Selenium 2 users as well because it came from Firefox changes.

Was Selenium 3 W3C-only?

No. It supported both JSON Wire Protocol and W3C WebDriver during the transition. Selenium 4 later removed legacy protocol support.

Should a new project start on Selenium 3?

No; treat Selenium 3 material as historical and follow the current Selenium downloads and setup documentation for a new project.