User-Agent Strings Explained: How to Read & Generate Them

Every HTTP request your browser sends carries a User-Agent header, and almost nobody reads it until something breaks: a feature flag misfires on Safari, a crawler gets blocked, or analytics misclassifies a device. This guide breaks the string down token by token, explains why it is stuffed with decades-old compatibility cruft, and shows how to generate fictional UA strings for QA and crawler testing without impersonating real people.

What is a user agent string and what is it for?

A User-Agent string is the text value of the HTTP `User-Agent` request header that identifies the software making a request, including its product name, version, layout engine, and host platform. Servers read it to adapt responses, gather analytics, and route traffic. It is client-supplied text, so it is editable and never a trustworthy proof of identity ^{[mdn-ua-header]}.

The header has shipped since the earliest HTTP specifications. RFC 9110, the current HTTP Semantics standard, defines `User-Agent` as a field whose value contains "product identifiers" with optional comments, ordered by significance, and warns that overly long or detailed values can leak fingerprinting data ^[rfc9110]. That warning is the seed of the whole UA reduction story later in this article.

How do you read a Chrome user agent string token by token?

Read a UA string left to right as ordered layers: a `Mozilla/5.0` compatibility prefix, a parenthesized platform comment (OS and CPU), the layout engine token, and one or more product tokens for the browser and its base. Each token is `Name/Version` and the parentheses hold free-form comments. Most tokens exist for backward compatibility, not accuracy ^{[mdn-ua-header]}.

Take a concrete desktop Chrome string and split it apart:

`Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/120.0.0.0 Safari/537.36`

The lesson: only two tokens in that line, `Chrome/120.0.0.0` and the OS comment, carry information a developer usually wants. The rest is sediment from twenty years of browsers copying each other to avoid getting served a downgraded page.

Why is the user agent full of legacy tokens like Mozilla and KHTML?

The UA string is full of legacy tokens because browsers historically copied each other's identifiers to pass server-side feature detection. In 1994, Netscape (codename Mozilla) gained frames; servers checked for the `Mozilla` token before sending frame markup, so every later browser claimed to be Mozilla-compatible to receive the modern page ^{[history-of-ua]}.

The pattern compounded with each browser generation. Internet Explorer claimed `Mozilla` and added `compatible; MSIE`. Safari's engine descended from KHTML, so it kept `KHTML, like Gecko`. Chrome forked Blink from WebKit yet still ships `AppleWebKit` and `Safari` tokens. The result is a string that reads like an archaeological dig where each layer was added to satisfy code that checked for an older browser.

And then Microsoft came and made Internet Explorer and called itself Mozilla/4.0 (compatible; MSIE), and there was great rejoicing... and the parsers got so confused that they all gave up and just said everyone is Mozilla.

This is why client-side feature detection (testing for an API's existence) beats UA sniffing. MDN and the WHATWG both recommend feature detection precisely because the UA string is unreliable by design ^{[mdn-ua-detection]}.

What does the user agent format look like for each major browser?

Each browser follows the same skeleton, `Mozilla/5.0 (platform) engine (engine-comment) product tokens`, but fills it with distinct markers. Chrome adds `Chrome/` and `Safari/`; Firefox adds `Gecko/` and `Firefox/`; Safari adds `Version/` plus `Safari/`; Edge appends `Edg/`. Mobile strings insert `Mobile` and device hints. Matching these patterns is how parsers classify traffic ^{[mdn-ua-header]}.

How do you tell Edge and Chrome apart?

Edge is built on Chromium, so its UA is identical to Chrome's right up to the end, where it appends `Edg/<version>` (no "e" on the end). Parse from the right: if you see `Edg/`, it is Edge; if `OPR/`, Opera; if `SamsungBrowser/`, Samsung Internet. A bare `Chrome/...Safari/537.36` with no trailing vendor token is plain Chrome.

How do you detect mobile from a user agent?

Mobile UAs include a `Mobile` token (Android Chrome) or `Mobile/<build>` (iOS Safari), plus a platform marker like `Android` or `iPhone`. Note that Android Chrome now reports the device model as the literal letter `K`, a deliberate consequence of UA reduction. For reliable mobile detection, prefer the `Sec-CH-UA-Mobile` Client Hint over string matching ^{[ua-ch-explainer]}.

What is User-Agent reduction and how do Client Hints replace the UA?

User-Agent reduction is Google's multi-phase program to freeze and shorten Chrome's UA string to a fixed, low-entropy template, removing minor version, patch, and detailed OS and device data. Sites that still need that information request it explicitly through User-Agent Client Hints, a set of `Sec-CH-UA-*` request headers and the `navigator.userAgentData` JavaScript API ^{[ua-reduction]}.

The motivation is privacy. The high-entropy bits in a full UA string (exact patch version, OS build, device model) contribute to passive fingerprinting, the same risk RFC 9110 flags ^[rfc9110]. By freezing those fields and gating the rest behind opt-in hints, the browser shrinks how much a server learns by default. Chrome's reduced desktop UA freezes the platform version and zeroes the minor build numbers; the device model on Android collapses to `K`.

Low-entropy hints (`Sec-CH-UA`, `Sec-CH-UA-Mobile`, `Sec-CH-UA-Platform`) are sent by default. High-entropy hints (architecture, full version, model, platform version) are only delivered after a server requests them via the `Accept-CH` response header, or read on demand through `navigator.userAgentData.getHighEntropyValues()` ^{[ua-ch-explainer]}. For QA, this means you must test both the legacy UA path and the Client Hints path.

How do you generate fake user agents for test data and crawler testing?

Generate fictional UA strings by emitting values that match real browser patterns (correct token order, plausible version numbers) and attaching them to test fixtures or synthetic accounts. Use them to exercise device-detection branches, rate-limit rules, and crawler-handling logic. Keep every UA fictional and pair it with documentation-range data so nothing maps to a real device or person ^[rfc9110].

Practical uses for developers and QA:

• Responsive and feature-branch testing: feed mobile, desktop, and tablet UAs through your detection layer to confirm each path renders correctly.
• Crawler-handling tests: simulate a bot UA to verify your robots logic, rate limits, and server-rendered fallbacks behave, without hammering anyone else's site.
• Analytics validation: send a known mix of UAs and assert your pipeline classifies browser, OS, and device buckets the way you expect.
• Client Hints coverage: pair each generated UA with matching `Sec-CH-UA-*` headers so both code paths are exercised in CI.

How do you keep generated user agents ethical and non-identifying?

Treat a generated UA like any synthetic identifier: it should describe a plausible-but-fictional client, not a real one. The standards bodies reserve specific ranges precisely so test data never collides with production. Mirror that discipline by combining fictional UAs with documentation IPs and reserved phone numbers, never real customer fingerprints.

Our generators follow exactly this approach. The fake person generator and the broader full identity toolset emit consistent, never-issued identifiers, so a generated UA travels alongside a fictional name, a documentation-range address, and a sandbox phone number. Nothing in the bundle resolves to a living person, which keeps the data usable for QA and safe for privacy review.

When you wire UA generation into automated tests, validate the strings at the boundary: confirm token order, reject malformed inputs, and log the generated value so a failing test is reproducible. A UA that does not parse in your own detector is a UA that will silently skew analytics in production.