User Agent Parser

What is a User-Agent string?

Every HTTP request carries a User-Agent header: a line of text the client uses to describe itself. Here is a modern one, taken apart:

Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/131.0.0.0 Safari/537.36
└────┬────┘ └──────────┬──────────┘ └──────┬──────┘ └─────────┬────────┘ └───────┬──────┘ └──────┬─────┘
  legacy         platform info         engine token      compatibility     actual browser   legacy token

Almost none of that is literally true. The browser is Chrome, not Mozilla. It does not use AppleWebKit; it uses Blink. It is not Safari. Every one of those tokens exists because at some point a website checked for it before deciding to serve modern content.

That history is why UA parsing is pattern matching against a curated database rather than reading a structured field. This page uses the ua-parser-js library, which maintains that database.

How to parse a string

1. Paste a string, or use your own The "Use my browser" button inserts what your browser is currently sending, which is handy for comparing against a value from a log.
2. Read the field table Browser, engine, OS, device and CPU are shown separately. A field the parser could not match reads "Not stated" instead of being filled with a guess.
3. Check the match count It shows how many of the five field groups matched a known pattern. Zero is a real answer, not an error — see below.
4. Copy the JSON if you need it The raw parser result is available as JSON for pasting into a ticket or a test fixture.

Why parsing is inherently imperfect

This is the most useful thing to understand about UA strings, and it is not a limitation of any particular parser.

Windows 11 is indistinguishable from Windows 10

Both report Windows NT 10.0. Microsoft never incremented the NT version in the UA string, so no parser can tell them apart. A tool that confidently says "Windows 11" from a UA string alone is guessing.

macOS versions froze at 10.15.7

Safari and Chrome both cap the reported macOS version at 10_15_7 regardless of the real version, deliberately, to reduce fingerprinting. A Mac running macOS 15 still reports Mac OS X 10_15_7.

iPads claim to be Macs

Since iPadOS 13, Safari on iPad sends a desktop macOS string by default. Device detection therefore reports a Mac, and there is no reliable way to distinguish them from the UA alone.

Chrome freezes its version and platform detail

Chromium's User-Agent Reduction programme deliberately caps the minor version at 0.0.0 and reduces platform detail. That is why every recent Chrome string ends 131.0.0.0 rather than a real build number.

Anyone can send anything

The header is a self-report with no verification. Browser devtools let you change it in two clicks, and every HTTP client sets whatever you tell it to. A UA string is a claim, not evidence.

Client Hints: the structured replacement

Chromium browsers expose navigator.userAgentData, which returns actual structured values instead of a string to be pattern-matched:

navigator.userAgentData
// {
//   brands: [
//     { brand: "Chromium",       version: "131" },
//     { brand: "Google Chrome",  version: "131" },
//     { brand: "Not_A Brand",    version: "24"  }
//   ],
//   mobile: false,
//   platform: "Windows"
// }

Two things are worth noting. The deliberately absurd "Not_A Brand" entry exists to break code that assumes a fixed position in the list — a lesson learned from the UA string era. And the fields shown by default are limited; details such as the full platform version require an explicit getHighEntropyValues() call, which is a separate, auditable request.

Firefox and Safari have not implemented Client Hints, so the UA string remains the only option there. When your browser supports it, this page shows both side by side so you can compare the structured answer with what the string claims.

Examples: what different clients produce

Two details in that table are worth dwelling on.

Desktop has no device type. The device.type field is only populated for mobile, tablet, console, smarttv, wearable and embedded. An empty device type usually means desktop, but it can also mean unrecognised — so it is reported as "Not stated" rather than asserted as desktop.

Bots return nothing. The base library's pattern database targets browsers, so Googlebot and curl match none of it. That is genuinely informative: when you are triaging server logs and every field comes back empty, the request almost certainly came from an automated client rather than a browser. Distinguishing which bot needs a separate crawler database, which this page does not include and does not claim to.

Use cases

• Reproducing a reported bug. A user pastes their UA into a support ticket; parsing it tells you the browser and engine to test against.
• Triaging server log entries. Working out whether a burst of requests came from real browsers or from scripts.
• Checking an analytics discrepancy. Comparing a raw UA string against how your analytics classified it explains an unexpected browser split.
• Verifying a spoofed UA in testing. Confirming that the string your automated test sets is being read the way you expect.
• Understanding what your own browser reveals. Seeing the string alongside Client Hints shows how much detail is actually exposed.
• Auditing a UA allowlist. If a firewall or CDN rule matches on UA substrings, parsing sample strings shows which real clients it would catch or miss.

Working through a request end to end? The URL Parser breaks down the target URL and the cURL to Fetch Converter turns a captured request into code.

Privacy

Parsing runs in your browser using the bundled pattern database. The string you paste is not uploaded. Reading navigator.userAgent and navigator.userAgentData happens locally, and no high-entropy Client Hint values are requested.

Usage analytics record only the parsed browser name, OS name and device type — coarse categories such as "Chrome" and "Windows" — never the raw string you pasted.