User-Agent Strings Explained: Format and Parser Test Cases

A User-Agent string is client-supplied text in an HTTP request header. It usually describes a product, version and optional platform details. RFC 9110 defines the field, but clients may omit or change it. A parser therefore needs an unknown path as well as rules for familiar browsers ^[rfc9110].

Decode a Chrome example

This historical Chrome 120 string is useful as a fixed parser fixture: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/120.0.0.0 Safari/537.36. Its version is illustrative; it is not a claim about the latest browser release.

Chromium’s reduction documentation shows frozen platform tokens and zeroed minor-version fields. Windows NT 10.0 and the Android model token K are deliberately coarse values ^{[chromium-reduction]}. Inferring a precise OS or device from them produces false precision.

Browser examples for a fixed regression corpus

These desktop and mobile strings cover specific patterns, not every browser. iOS browser branding, embedded webviews, unusual clients and future reduced strings need their own samples. A Chrome token without Edg/ is still not proof of Google Chrome: other Chromium-based clients can report the same form ^{[mdn-detection]}.

Parser cases that a happy-path example misses

What changes with User-Agent Client Hints?

In supporting Chromium browsers, low-entropy hints include Sec-CH-UA, Sec-CH-UA-Mobile and Sec-CH-UA-Platform. Over secure connections these can be sent by default. A server can request additional details with Accept-CH, for example Accept-CH: Sec-CH-UA-Platform-Version. The browser still controls which values it returns ^{[chrome-hints]}.

Client Hints use structured header values: Sec-CH-UA is a brand list, not one browser name. Test unknown brands and different ordering. If you vary a cacheable response using a hint, make the cache vary on the relevant header as well, or different clients may receive the same cached variant ^{[chrome-hints]}.

Changing a header is not browser emulation

A custom User-Agent can exercise a server parser, analytics bucket or response-selection branch. It does not install Safari, change a JavaScript engine, resize a viewport or create touch support. For a feature-dependent UI, test the feature itself and exercise the real browser engine you support ^{[mdn-detection]}.

There is no reserved fictional User-Agent range. Many real clients share a string, so a generated value can match one without identifying an individual. Avoid claiming that a plausible UA is guaranteed never to belong to a real device.

What Fakenamely generates

The identity generator currently selects a User-Agent from five fixed historical strings: Windows Chrome, macOS Safari, Windows Firefox, Linux Chrome and iPhone Safari. It does not generate every browser/version combination or attach a matching Client Hints bundle. Use the explicit corpus above when you need predictable branch coverage.

For related fixture fields, see IP documentation ranges and MAC address formats. Those pages explain their own address semantics; neither IP nor MAC values can establish the truth of a User-Agent header.