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.
What a headless browser is
A headless browser is a normal browser engine running without a graphical window, driven programmatically. Frameworks such as Puppeteer and Playwright automate Chromium, Firefox, or WebKit for testing, rendering, and scraping.
Because they run a real engine, headless browsers execute JavaScript and look more like browsers than a simple HTTP script does, which is why behavioural signals matter alongside the user agent.
How headless clients can identify themselves
Headless Chrome has historically included a HeadlessChrome token in its user agent, which is a clear automation signal when present. However, automation frameworks can override the user agent to mimic an ordinary browser, so the token's absence does not rule out automation.
The exact tokens depend on the framework and version, so verify specific strings against the tool's documentation rather than assuming. Treat a HeadlessChrome token as a reliable positive signal, and lean on behaviour for the rest.
- HeadlessChrome token: a clear automation signal when present
- Puppeteer/Playwright drive real engines and can override the UA
- Absence of the token does not prove a human visitor
How it appears in analytics and logs
A user agent containing a HeadlessChrome token is a strong automation signal. Headless tools can also use a normal browser string, so absence of the token does not prove a human; corroborate with other signals.
Diagnostic use case
Recognise automated headless-browser traffic from tools like Puppeteer and Playwright so it is counted as automation rather than as human sessions.
What WebmasterID can help detect
WebmasterID classifies recognisable headless and automation patterns server-side as bot traffic, keeping them out of human analytics, and keeps unconfirmed cases in an honest 'other' bucket.
Common mistakes
- Assuming all headless automation reveals itself with a HeadlessChrome token.
- Counting headless rendering or testing traffic as human sessions.
- Relying on the UA alone when frameworks can override it.
Privacy and accuracy notes
Headless detection uses the request user agent and behavioural signals, not visitor identity. WebmasterID records headless automation as a bot event, never as a human profile.
Related pages
- Spoofed and fake user agents: what to watch for
Spoofing a user agent is trivial — any client can claim to be Googlebot or a normal browser. This page explains why spoofing happens, the common fake-crawler patterns, and the verification methods that turn a claimed identity into a confirmed one.
- curl, wget and script user agents
Command-line and library HTTP clients send a default user agent that names the tool: curl/x.y, Wget, python-requests, Go-http-client, and similar. These are scripts, not browsers, and seeing them is normal. This page explains the patterns and how to treat them without over- or under-reacting.
- Bot vs human traffic
Separate automation, including headless browsers, from real people.
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.