How User Agent Parser works
A user agent string is the self-description a browser sends with every request, and it is one of the strangest artefacts in web technology — a compatibility fossil in which nearly every browser claims to be several others. This parser pulls out the browser, its version, the rendering engine, the operating system and the device type, testing the most specific tokens first because that layered impersonation makes order essential. It is genuinely useful for reading analytics data and reproducing a reported bug, and genuinely unsuitable for deciding which features to use, for reasons covered below.
How to use it
- 1
Paste a user agent string, from your analytics, a server log or a bug report.
- 2
Read the parsed browser, version and rendering engine.
- 3
Check the operating system and device type classification.
- 4
Compare against the reporter's description if you are reproducing an issue.
Why every browser lies about what it is
The prefix Mozilla/5.0 appears on essentially every browser in existence, and the reason is a compatibility spiral that began in the 1990s. Early servers checked whether a browser identified as Mozilla before serving frames-capable HTML, so competing browsers added the token to avoid being handed a degraded page. Every browser since inherited it, because removing it risks being misidentified by server-side checks that still exist somewhere. The pattern repeated at every generation: Chrome claims Safari because it began with WebKit and wanted WebKit-targeted content, Edge claims both Chrome and Safari so it receives whatever Chrome receives, and Opera claims Chrome for the same reason. The practical consequence for parsing is that tokens must be tested from most specific to least — check for Edg before Chrome, and Chrome before Safari — because otherwise every Chromium browser is identified as Safari. Any parser that tests in the wrong order produces confidently wrong answers.
Use feature detection instead
Parsing a user agent to decide whether to use an API is a well-established mistake, for several compounding reasons. The string is trivially spoofed, so it is not trustworthy input. It goes stale, because a parser encoding today's browsers misclassifies browsers that ship next year — and the usual failure mode is excluding a capable new browser from a feature it supports perfectly. Privacy features and reduced-UA initiatives are actively removing detail from the string, with Chromium freezing much of its content and moving structured data to User-Agent Client Hints instead. Feature detection avoids all of this by asking the only question that matters: does the capability I need exist right now? Checking whether a method is present, or using CSS @supports for a property, is accurate by construction and requires no maintenance as the browser landscape changes. Reserve UA parsing for analytics and diagnostics, where you are describing traffic rather than making a decision.
Where this helps
Reproducing a reported bug
A UA string from a support ticket tells you which browser and OS version to test against, which is often the whole diagnosis.
Reading server logs
Identifying which requests came from bots rather than real visitors changes how traffic figures should be read.
Understanding analytics data
Analytics tools report parsed values, and seeing the raw string explains why a browser was categorised the way it was.
Checking what your own browser reports
Useful when debugging a UA-based rule on a server or CDN that is behaving unexpectedly.
Tips
- Test browser tokens from most specific to least — Edg before Chrome, Chrome before Safari — or every Chromium browser looks like Safari.
- Never gate a feature on a parsed user agent; check for the feature itself with a capability test or CSS @supports.
- Treat UA strings as untrusted input: they are set by the client and are routinely spoofed by bots and privacy tools.