A user agent string looks like noise the first time you see one — a run-on line of parentheses, slashes, and version numbers. It isn't random. Every browser follows a loose but consistent format, and once you know what to look for, you can read one almost as easily as a sentence.

The parts every string shares

Nearly every modern browser starts its user agent with Mozilla/5.0. This is a historical artifact, not a lie about the browser's identity — in the mid-1990s, sites checked for "Mozilla" to decide whether to serve advanced features, and every subsequent browser kept the token so it wouldn't get treated as inferior. It's the single most misleading-looking part of any user agent, and also the most meaningless.

After that comes a parenthetical block describing the platform — the operating system, sometimes the device, sometimes the CPU architecture. Then, outside the parentheses, a sequence of product/version pairs describing the rendering engine and the browser itself, roughly in the order those layers were added historically.

Chrome

A typical Chrome string on Windows reads: platform info, then AppleWebKit/537.36 (KHTML, like Gecko), then Chrome/<version>, then Safari/537.36 at the end. Chrome mentions both AppleWebKit and Safari because it's built on the WebKit-derived Blink engine and keeps those tokens for compatibility with sites that check for them — not because Chrome and Safari share a codebase today. The Chrome/ token is the one that actually identifies the browser and its version.

Firefox

Firefox's format is shorter and more direct: platform info including an rv: (revision) token, then Gecko/20100101 — note that date never changes, it's a fixed legacy value — followed by Firefox/<version>. Firefox is one of the few major browsers that doesn't pad its string with compatibility tokens for other engines, which makes it noticeably shorter than a typical Chrome or Safari string.

Safari

Safari's string includes AppleWebKit/<build>, then Version/<Safari version> — this is the actual Safari version number, separate from the WebKit build number next to it — followed by Safari/<build> again at the end. The double appearance of a similar-looking number is the most common point of confusion: the Version/ token is what you want if you're trying to identify which Safari release it is.

Chromium-based browsers: Edge and Opera

Edge and Opera are both built on the same Blink engine as Chrome, so their strings look almost identical to Chrome's, with one addition near the end: Edg/<version> for Edge, or OPR/<version> for Opera. Servers and scripts that only check for the word "Chrome" will treat Edge and Opera traffic as Chrome traffic unless they specifically look for these extra tokens — which is exactly why they're worth checking for if you need to tell the three apart.

Mobile adds another layer

On Android, Chrome's string gains a Mobile token and reports the device model in the platform section. On iOS, browsers other than Safari itself have to identify differently — Chrome on iOS uses CriOS/, Firefox uses FxiOS/ — because Apple requires all iOS browsers to use its WebKit engine under the hood, so the underlying AppleWebKit and Safari/ tokens show up regardless of which browser you're actually using.

Once you know which tokens actually identify the browser versus which ones are compatibility leftovers, a user agent string stops looking like noise and starts looking like a fairly literal readout of what's rendering the page.