Why Selenium is still relevant in 2026
Three durable reasons to pick Selenium:
- Safari support. Playwright's WebKit isn't Safari — it's the WebKit rendering engine without Safari's actual app around it. Testing or scraping real Safari requires Selenium plus safaridriver (Apple's WebDriver helper for Safari).
- Mobile browsers. Appium (the mobile sibling of Selenium) drives mobile Chrome, mobile Safari, and native phone apps through the same WebDriver API. No other framework reaches all of that.
- Existing test code. Half of QA automation in the enterprise is Selenium. If your team already maintains a test suite, reusing the framework for scraping is faster than rewriting it.
For a brand-new ("greenfield") Python or Node Chromium scraper, Playwright is the better pick — a more modern API, faster startup, and better parallelism (running many browsers at once). Selenium's WebDriver wire protocol — the back-and-forth messaging used to send each command to the browser — adds about a millisecond of overhead per command, which adds up over a long script.
Selenium's detection surface
Of the three big browser-automation frameworks, Selenium is the easiest for anti-bot systems to spot, because it leaves several telltale signs (fingerprints):
- WebDriver is W3C-standardised to set
navigator.webdriver = true. Every Selenium browser exposes this flag by default, and any website can read it in one line of JavaScript. Anti-bot scripts test it as their first check. - Selenium injects identifying properties into
window— keys likewindow.cdc_*,window.$cdc_*, and others (windowis the global object every web page can inspect) that anti-bot scripts scan for. - The WebDriver wire protocol leaves timing artifacts — the delay between a command and its response differs from real human input by a measurable amount.
- The chromedriver binary itself (the helper program that controls Chrome) has shipped with the substring "$cdc_" in its source for years — only recently patched in the mainline version.
Plain, unmodified ("vanilla") Selenium gets blocked on any modern protected site. The fixes are the stealth variants in the next section.
undetected-chromedriver and SeleniumBase UC mode
Two production-ready ways to make Selenium stealthier:
- undetected-chromedriver (UC) — patches the chromedriver binary as it downloads to strip out the
$cdc_strings and resetnavigator.webdriver. This satisfies most basic (Layer-1 and Layer-2) checks. It is still visible to Function.toString() inspection — a trick where a site reads the source code of the override function and sees it was tampered with. - SeleniumBase UC mode — wraps undetected-chromedriver in a pytest-friendly API (pytest is the standard Python test framework), adds automatic clicking of the Cloudflare Turnstile challenge, and gives you a clean set of
sb.uc_*methods. This is the default choice when you want Selenium plus stealth plus a test framework. - selenium-driverless — drops the WebDriver layer entirely and drives Chrome straight through raw CDP (Chrome DevTools Protocol, the browser's native control channel). This removes the WebDriver fingerprint, but you also lose the cross-browser support that made you choose Selenium in the first place.
Even with UC, Selenium still loses to Kasada, F5 Shape, and recent Akamai. For those, switch to Camoufox, CloakBrowser, or a managed API — at that point the WebDriver protocol itself is the bottleneck.
