Can websites detect Selenium?

Yes, easily in its default setup. The W3C WebDriver standard has the browser set navigator.webdriver to true while under WebDriver control, and ChromeDriver adds cdc_ variables to the page that a script can read.

How do people set navigator.webdriver to false in Selenium?

Usually with the Chrome flag --disable-blink-features=AutomationControlled or with undetected-chromedriver. That is why detection should not rest on the flag alone.

Does undetected-chromedriver still work?

It still gets about 605,700 weekly downloads, but its last release was Feb 17, 2024 and it warns that it does not hide your IP. Scripted behavior and datacenter networks still give many of its sessions away.

What is the cdc_ variable in ChromeDriver?

It is a property, document.$cdc_asdjflasutopfhvcZLmcfl_, that stock ChromeDriver adds to the page and that sites check for. Bot operators remove it by recompiling or hex-editing ChromeDriver, or with undetected-chromedriver.

Is Selenium or Playwright easier to detect?

Stock Selenium is generally easier, because WebDriver sets the webdriver flag by standard and ChromeDriver adds cdc_ variables. Both get much harder once stealth patches are added, and Verisoul returns them under different ids, webdriver and cdp_automation.

How to detect Selenium | Verisoul Agent Atlas

Selenium is an open source project, a member of the Software Freedom Conservancy, that controls real browsers through language bindings and per-browser drivers such as ChromeDriver and geckodriver. Selenium 4.0.0 shipped on Oct 13, 2021, and the project still releases often, with 4.52.0 out on Oct 29, 2026. It powers a large share of automated testing, and the same code drives sneaker bots, appointment bots and survey farms.

It remains widely installed. The selenium Python package logged about 7.5M downloads in the week to Nov 1, 2026, and selenium-webdriver on npm about 2.2M in the week of Oct 23 to Oct 29. Teams usually ask about it after a wave of scripted sign-ups or bookings, because it is the first tool many bot operators learn.

How Selenium shows up on your site

Selenium runs the real browser, so the user agent is the real Chrome, Firefox, Edge or Safari string, and old-style headless Chrome may still show HeadlessChrome. The tell sits inside the browser: the W3C WebDriver spec has the browser set navigator.webdriver to true whenever WebDriver is in control, which makes automation something the browser is supposed to announce. Selenium 4 also exposes DevTools and BiDi features for Chromium and Firefox.

Check	What Selenium does
User agent	The real browser's string, sometimes HeadlessChrome
Web Bot Auth signature	None, Selenium has no signing support
IP ranges	None, often datacenter or residential proxies
robots.txt	Not checked by the library

Why Selenium is easy to detect

Stock Selenium declares itself by standard, because the webdriver flag is set by the browser and ChromeDriver adds its own cdc_ variables to the document, such as document.$cdc_asdjflasutopfhvcZLmcfl_, which may only appear after the script first interacts with the page. A script on your site can read both in a few lines, which makes the default setup the easiest of the automation libraries to catch.

Operators know this, which is why undetected-chromedriver still gets about 605,700 weekly downloads even though its last release, 3.5.5, came out on Feb 17, 2024. It patches ChromeDriver to remove the flag and the cdc_ variables, and others get the same result by recompiling or hex-editing the driver, while the project's own page warns that it does not hide your IP. Once those markers are gone, the session still behaves like a script and often still arrives from a datacenter, so detection moves to behavior and network.

How Verisoul detects Selenium

Selenium doesn't sign anything or publish an identity, so Verisoul reads what the browser declares. Our SDK checks for the WebDriver automation flag and driver artifacts in the browser, then pairs that with session behavior, where scripted navigation with no human input stands out. Any browser under WebDriver control comes back under the same id, whichever language binding launched it.

API response

"agent": {
  "id": "webdriver",
  "name": "WebDriver",
  "provider": "Open source",
  "type": "headless_automation",
  "detection_method": "self_declared",
  "detection_signals": [
    "network",
    "device",
    "behavioral"
  ]
}

id is webdriver, the stable value to write rules against for any WebDriver-controlled browser
type is headless_automation, which groups scripting libraries apart from AI assistants and crawlers
detection_method is self_declared, because the browser announced its own automation
detection_signals lists device (the webdriver flag and driver artifacts) and behavioral (scripted navigation with no human input)

See the WebDriver entry in Agent Atlas and the AI agent detection docs for the full response format.

01Operator runs a Selenium script
02ChromeDriver opens a real Chrome
03Browser sets navigator.webdriver to true
04Your page sees the flag and artifacts

How Selenium reaches your site

How to detect Selenium step by step

Add the Verisoul SDK to sign-up, login, booking and payout pages
Read the agent object in the Verisoul API response and look for webdriver
Allowlist your own Selenium Grid, then block or challenge webdriver on the steps you protect
Review sessions with a high bot score and no agent name, which is where patched drivers usually land

Should you block Selenium?

On sign-up, login, booking and payout pages, a Selenium session is a script, often a ticket, appointment or rewards bot, so blocking webdriver there is a safe default. Keep a separate allowlist for your own test grid so QA doesn't trip the rule.

On public pages it is usually a scraper, which is a rate-limiting question more than a fraud one. Most teams let it read and stop it at the first step that creates an account or moves value.

Selenium