Selenium WebDriver user agent
Selenium automates real browsers through the W3C WebDriver protocol. Because it controls an actual browser, its user agent is the browser's own, with no Selenium token by default. The reliable tell is the WebDriver automation state (navigator.webdriver) and behavioural signals, not the user-agent string.
What this means
Selenium uses the WebDriver protocol to remote-control browsers like Chrome and Firefox. Because it drives the real browser, the user agent it sends is the browser's normal string — there is no Selenium token in it by default.
That means the user agent cannot be used to identify Selenium. Like Playwright and Puppeteer, Selenium traffic blends in because it is a genuine browser being puppeteered.
How Selenium reveals itself
Under WebDriver control, the navigator.webdriver property is set to true per the W3C WebDriver specification. This is the primary, spec-defined signal. Additional tells include automation-specific browser flags, missing or unusual browser features, and non-human interaction patterns.
Operators can attempt to mask navigator.webdriver and other signals, so detection is probabilistic. Combine signals and avoid trusting the user agent, which carries no reliable Selenium marker.
- User agent is the controlled browser's own — no Selenium token
- navigator.webdriver is true under WebDriver automation
- Automation flags and behaviour add corroborating signals
How to treat this traffic
If Selenium is your own (end-to-end testing), give it a custom user agent so your logs distinguish test runs from real users. If you are defending against unwanted automation, lean on navigator.webdriver plus behavioural signals and rate limiting rather than UA-substring rules.
Because Selenium drives a real browser, it executes JavaScript and loads assets, so client-side detection differs from catching plain HTTP clients that never run scripts.
How it appears in analytics and logs
A Selenium-driven request carries the controlled browser's user agent. There is no default Selenium marker in the UA, so identification depends on WebDriver signals such as navigator.webdriver and on behaviour, not the string.
Diagnostic use case
Understand why Selenium traffic looks like an ordinary browser and which WebDriver signals actually reveal the automation.
What WebmasterID can help detect
WebmasterID relies on automation signals server-side rather than the browser-like user agent, so Selenium-driven traffic can be separated from human visits where the signals are available.
Common mistakes
- Expecting a Selenium token in the user agent — there is none by default.
- Trying to block Selenium by UA substring rather than WebDriver signals.
- Treating navigator.webdriver alone as unspoofable proof.
Privacy and accuracy notes
Detecting WebDriver automation uses capability and behavioural signals, not human identity. WebmasterID treats confirmed automation as a bot event, separate from human analytics, without fingerprinting users.
Frequently asked questions
- Is there a Selenium user-agent string?
- No default one. Selenium drives a real browser, so it sends that browser's user agent. Detection relies on navigator.webdriver and behaviour, unless the operator sets a custom UA themselves.
Related pages
- Playwright and Puppeteer user agents
Playwright and Puppeteer are browser-automation libraries that drive real Chromium, Firefox, or WebKit instances. Because they use the actual browser engine, their default user agent matches a normal browser — sometimes with a HeadlessChrome marker — so the user agent alone rarely reveals them. Detection relies on automation signals, not the string.
- Headless browser user agents
Headless browsers run a real browser engine without a visible window, and are widely used for testing and scraping. Headless Chrome historically exposed a HeadlessChrome token, though automation can also wear an ordinary browser string. This page explains the patterns and why headless traffic is automation.
- Detecting automation from user agents
You can use the user agent as a first signal for spotting automation — tool tokens, headless markers, missing strings — but it is never conclusive, because any client can change it. Reliable detection pairs the UA with verification and behaviour, and records honest unknowns. This page explains a sound approach.
- Bot vs human
Separate WebDriver automation from genuine human visits.
Sources and verification notes
Last reviewed 2026-06-24. Facts are checked against primary/official sources where available; uncertain specifics are marked “Data not yet verified” rather than guessed.