Browser user agents: how to read them
A browser user-agent string packs several tokens into one line: a legacy Mozilla prefix, a rendering-engine signature, the platform, and the browser itself. This page explains each part so you can read a UA without over-reading it, because the contents are client-controlled and can be copied by any client.
The anatomy of a browser UA
A browser user-agent string is a sequence of tokens. It typically starts with the legacy Mozilla/5.0 prefix, followed by a platform descriptor in parentheses, then a rendering-engine signature (such as a WebKit or Gecko token), and finally the browser's own product token and version.
No single token is authoritative on its own. The string is meaningful only as a whole, and even then it is a claim the client chose to send.
- Mozilla/5.0 prefix: legacy, present on almost every browser
- Parenthesised section: platform/OS descriptor
- Engine signature: e.g. a WebKit or Gecko token
- Browser product token + version: the actual browser
Match on patterns, not exact strings
User-agent strings change with every browser release, and modern browsers are deliberately reducing the detail they expose. Hard-coding an exact string breaks quickly. Match on the stable pattern — the presence of an engine or product token — rather than a full version string.
MDN documents the User-Agent header and warns against UA sniffing for feature detection; prefer capability checks where you can.
How it appears in analytics and logs
A user agent shaped like a full browser string usually came from a browser, but a scraper can reproduce the same shape. Read the engine and platform tokens for context, not as a guarantee of identity.
Diagnostic use case
Read a browser user agent in logs or analytics to tell roughly which engine and platform sent a request, while remembering the string is a self-report, not proof.
What WebmasterID can help detect
WebmasterID parses browser user agents server-side into a coarse browser/engine category against a maintained signature list, keeping unknown clients in an honest 'other' bucket instead of guessing a name.
Common mistakes
- Reading the Mozilla/5.0 prefix as meaning Firefox.
- Hard-coding an exact user-agent string that breaks on the next release.
- Treating a browser-shaped string as proof the client is a real browser.
Privacy and accuracy notes
Browser user agents do not identify a person; they describe software. Parsing them into a coarse browser/platform category is privacy-safe. WebmasterID classifies at ingest and does not expose the raw strings of real visitors.
Related pages
- Chrome user agent and its quirks
Chrome's user-agent string is full of historical artefacts: it claims AppleWebKit and Safari for compatibility even though Chrome uses the Blink engine. Google has also reduced the detail Chrome exposes in the UA, moving fine-grained information into User-Agent Client Hints. This page explains the pattern and the quirks.
- Bot vs browser user agents: how to tell them apart
A user-agent string is a self-reported label, not an identity. This page explains how declared bots name themselves, why almost every UA still starts with the legacy Mozilla token, and how to read the difference between an automated client and a real browser without over-trusting the string.
- Bot vs human traffic
How automation is separated from people across your traffic.
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.