User agent parser

What Is a User Agent (and Why Parse It)?

Every HTTP request your browser sends carries a User-Agent header — a text string in which the client introduces itself to the server. A typical desktop Chrome string looks like this:

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

To the untrained eye it is gibberish; to a parser, it is a structured dossier: operating system (Windows 10/11 64-bit), rendering engine (AppleWebKit/Blink lineage), browser (Chrome 126), and a trail of historical tokens (Mozilla/5.0, KHTML, like Gecko, Safari/537.36) that exist only because of decades of browser-compatibility hacks. A user agent parser decodes this string into its components — browser name and version, OS and version, device type (desktop, mobile, tablet, bot), and engine — turning an opaque token into actionable data.

Why does anyone care? Because servers adapt to clients. Analytics platforms segment visitors by browser and OS ("what share of our users are on old Safari?"). Developers serve fallbacks to legacy browsers and debug "works on my machine" reports by reproducing the exact client. Security teams spot scrapers and credential-stuffing bots by their UA signatures. Ad platforms and fraud systems weigh the UA as one signal among many. And website owners investigating a weird log entry paste the UA into a parser to learn it was just Googlebot, not an attack.

The parsing challenge is that UA strings were never standardized — they accreted over three decades of browser wars, compatibility hacks, and marketing. The Mozilla/5.0 prefix is a fossil from the 1990s: every browser claims to be Mozilla because sites once served degraded pages to unknown browsers. Mobile strings add device models (SM-G991B, iPhone16,2), bots identify themselves (Googlebot/2.1, bingbot/2.0) — or spoof browsers to evade blocks. Then Google began freezing and reducing the UA string (User-Agent Reduction), moving detail into Client Hints (Sec-CH-UA headers) that servers must explicitly request. A modern parser handles both worlds: classic UA strings and the Client Hints that supplement them, giving you continuity across the transition. Parsing is processed instantly and never stored.

Anatomy of a User Agent String

The golden rule of reading UA strings: the last browser token usually wins. In the Chrome example above, Safari/537.36 is camouflage and Chrome/126.0.0.0 is the truth. Edge's string ends with Edg/126.0.0.0 after the Chrome token; Opera's ends with OPR/.... Bots are the exception — they typically lead with their identity (Googlebot/2.1) because they want to be recognized for crawl-rate purposes. A parser encodes these precedence rules so you do not have to memorize them.

Famous User Agent Strings, Decoded

Nothing teaches UA reading like real specimens. Here are four, with translations:

Desktop Chrome (Windows):
Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/126.0.0.0 Safari/537.36
→ Chrome 126, 64-bit Windows 10/11, Blink engine. The Safari token is camouflage; the Chrome token is truth.

iPhone Safari:
Mozilla/5.0 (iPhone; CPU iPhone OS 17_4 like Mac OS X) AppleWebKit/605.1.15 (KHTML, like Gecko) Version/17.4 Mobile/15E148 Safari/604.1
→ Safari 17.4 on iOS 17.4. Note: on iOS, all browsers use WebKit (Apple's App Store rule), so "Chrome on iPhone" still parses as WebKit underneath — the engine field matters more than the brand here.

Googlebot:
Mozilla/5.0 (compatible; Googlebot/2.1; +http://www.google.com/bot.html)
→ Google's crawler, openly identified with a documentation URL. The compatible; prefix is the polite bot convention.

curl (the classic imposter):
curl/8.0.1
→ The command-line tool, honest about it. Many sites block this outright — which is why scrapers spoof Chrome instead, and why a "Chrome" UA doing curl-like things is suspicious.

Work through these with the parser's token breakdown and the pattern becomes intuitive: find the last browser token, read the parenthesized platform block, and treat everything else as archaeology.

User-Agent Reduction and Client Hints

Since 2021, Chrome has progressively frozen UA detail: minor versions became .0.0, and the OS version stopped updating, all to curb passive fingerprinting — the practice of identifying users by the unique combination of their browser characteristics. The replacement is Client Hints — structured headers like Sec-CH-UA: "Chromium";v="126", "Google Chrome";v="126", Sec-CH-UA-Platform: "Windows", and Sec-CH-UA-Mobile: ?0 that servers request explicitly via Accept-CH. High-entropy hints (exact OS version, device model, full browser version) require that opt-in, so users and browsers control disclosure instead of broadcasting it to every site. For parsers, this means the classic string is increasingly coarse while the real detail moved to headers you only see if the server asked for them. The parser handles both: paste a UA string, or paste the Client Hints headers alongside it, and get the complete picture. Safari and Firefox have kept richer classic strings, so cross-browser parsing still leans on the old format there — for now.

How to Use the User Agent Parser

Follow these steps to decode any user agent string:

1. Paste the UA string. Copy it from your server logs, analytics export, bug report, or the HTTP headers lookup (which shows the UA your own browser sends).
2. Run the parse. The tool tokenizes the string and applies browser-precedence rules to identify the real client behind the compatibility tokens.
3. Read the browser result. Get the browser name and full version (e.g., Chrome 126.0.0.0, Safari 17.4, Firefox 127.0) — the single most useful field for compatibility decisions.
4. Read the OS and device. See the operating system and version (Windows 11, macOS 14.5, Android 14, iOS 17.4) plus the device class: desktop, mobile, tablet, smart TV, or bot.
5. Check the engine. Blink, WebKit, or Gecko determines which CSS and JS behaviors to expect — more predictive than the brand name for rendering bugs.
6. Review the bot verdict. The parser flags known crawlers (Googlebot, Bingbot, social preview bots like facebookexternalhit) and notes whether the string looks spoofed — a "Chrome" UA from a datacenter IP behaving like a scraper deserves suspicion.
7. Add Client Hints if you have them. Paste Sec-CH-UA* headers alongside the UA string for the detailed version and platform data that reduced UAs no longer carry.
8. Batch-parse log excerpts. Paste multiple UA strings (one per line) to profile a traffic sample — instantly see the browser/OS mix of your error-log entries, your most suspicious visitors, or the audience behind a traffic spike.

Key Features

The token-by-token breakdown is the sleeper feature: instead of just giving you "Chrome 126 on Windows," it walks through each token in the string and explains what it means and which ones are historical camouflage. After parsing a few strings this way, you start reading raw UAs fluently — a genuinely useful skill when you are tailing logs at 2 AM and cannot reach for a tool. It also demystifies the perennial confusion of "why does Chrome claim to be Safari?" (answer: 1990s compatibility hacks, fossilized forever) and "why does every mobile string say Mozilla?" (same reason). Understanding the archaeology makes the modern Client Hints migration click: the industry finally admitted the string was a mess and built a structured replacement.

Parsing Pitfalls: When the String Lies

Even good parsers face adversarial input, and knowing the failure modes keeps you honest. Spoofing is the big one: scrapers, bots, and privacy tools routinely send Chrome's exact string, so "Chrome 126 on Windows" in your logs might be a Python script. The tell is behavioral — inhuman request rates, missing asset requests (real browsers fetch CSS, images, and fonts; scrapers often fetch only HTML), and datacenter IPs. In-app browsers (Facebook, Instagram, TikTok webviews) send hybrid strings that parsers may misclassify as the underlying engine rather than the app. Corporate proxies and security gateways sometimes rewrite or strip UAs entirely, producing blank or generic strings for thousands of real users.

Then there is freezing: Chrome's reduced UA reports Windows NT 10.0 even on Windows 11 and .0.0 minor versions, so version-level analytics from the classic string are now coarse by design — another reason to capture Client Hints server-side if you need precision. The professional stance: parse the UA for what it is (a self-reported claim), corroborate with behavior and network signals, and never gate security decisions on it alone. A login form that trusts the UA is a login form waiting to be bypassed.

Use Cases

Developers Reproducing "Works on My Machine" Bugs

The problem: A user reports a broken layout, and all you have is "it doesn't work on my browser." Without the exact browser, version, OS, and engine, you cannot reproduce it — and asking the user for technical details usually yields "the blue one."

How this tool helps: Paste the UA from your analytics or error-tracking tool (most capture it automatically) and get the precise client profile: not just "Safari" but "Safari 16.4 on iOS 16.4" — the version where a specific flexbox bug lived. The engine field tells you whether to expect a WebKit quirk or a Blink one, narrowing the search before you open dev tools. When the report includes a screenshot that looks fine to you, the parsed OS version often reveals the reporter is on an older platform where your modern CSS genuinely fails — turning a "cannot reproduce" into a "fixed with a fallback." For network-level context, the ping tool can check whether the user's region can even reach your server cleanly.

Analysts Segmenting Traffic

The problem: Leadership asks "should we still support IE11?" or "how many users are on old Android?" — questions answerable only from the browser/OS distribution of real traffic. Raw UA strings in a log export are not an answer; aggregated, classified data is.

How this tool helps: Batch-parse a sample of UA strings from your logs to build the distribution: browser share, OS versions, mobile vs. desktop split, bot percentage. That table is what justifies dropping legacy support (or keeping it) with data instead of opinions — "0.3% of traffic on IE11" ends the debate instantly, while "12% on Android 9" tells you the cutoff needs care. The bot identification also cleans the numbers — crawler traffic excluded, your "users" are actually users, and your conversion rates stop being diluted by Googlebot's enthusiasm.

Security Teams Triaging Suspicious Requests

The problem: The WAF flagged a burst of requests with odd UA strings. Is it a new legitimate client (an in-app browser, a corporate proxy), a known scraper, or an attacker spoofing Chrome to blend in?

How this tool helps: Parse the UA for its claimed identity, then compare against behavior: a "Chrome 126 on Windows" that fetches only API endpoints at machine speed is spoofed automation regardless of what the string claims. Known bot signatures get identified outright, and the token breakdown exposes Frankenstein strings (desktop OS token + mobile indicators, or a 2015 browser version with 2024 feature requests) that legitimate browsers never produce. Cross-reference with the safe URL checker when the suspicious traffic traces back to links you do not recognize. UA analysis never proves legitimacy — it is one signal — but it efficiently sorts the obviously-automated from the plausibly-human.

Students Learning Web Fundamentals

The problem: "The browser tells the server what it is" sounds simple until you see an actual UA string — a 150-character fossil bed of browser-war history. Without a guide, students cannot connect the string to the concepts of content negotiation and progressive enhancement.

How this tool helps: Paste your own browser's UA (via the headers lookup) and watch it decode into the browser you are actually using — the "aha" moment when the Safari token turns out to be Chrome in disguise. Comparing desktop, mobile, and bot strings side by side teaches why servers cannot trust the UA blindly, which motivates the entire Client Hints redesign. Then try the famous specimens above: decoding each one by hand before checking against the parser builds the pattern-recognition that turns a dry standards topic into internet archaeology you will actually remember.

Frequently Asked Questions

What is a user agent string?

A user agent string is a text header browsers and other HTTP clients send with every request, identifying the software making the request — typically the browser name and version, operating system, and rendering engine. Servers use it for analytics, compatibility decisions, and bot detection.

How do I find my browser's user agent?

Run the HTTP headers lookup on any URL — it shows the User-Agent header your browser sends. Or paste navigator.userAgent into any browser's developer console for the same string.

Why does Chrome's user agent say Safari and Mozilla?

Historical compatibility hacks. In the 1990s, sites served better content to browsers identifying as Mozilla, so everyone adopted the token; the Safari/KHTML tokens come from Chrome's WebKit lineage. They are fossils — the real identity is the Chrome/x.x token near the end.

Can user agent strings be faked?

Trivially. Any client can send any UA string, and scrapers routinely spoof popular browsers. Never use the UA alone for security decisions — treat it as a hint, corroborated by behavior, IP reputation, and (for sensitive actions) real authentication.

What are Client Hints?

Client Hints are structured HTTP headers (Sec-CH-UA, Sec-CH-UA-Platform, Sec-CH-UA-Mobile) that replace the detail Google removed from Chrome's UA string during User-Agent Reduction. Servers must explicitly request them, and high-detail hints need user opt-in — a privacy improvement over the always-on classic string.

How do I detect bots from the user agent?

Legitimate crawlers identify themselves (Googlebot/2.1, bingbot/2.0, facebookexternalhit). The parser flags these known signatures. But malicious bots spoof real browsers, so bot detection combines the UA with behavioral signals — request rate, URL patterns, and IP reputation — never the string alone.

What is the difference between Blink, WebKit, and Gecko?

They are browser rendering engines: Blink powers Chrome and Edge, WebKit powers Safari, and Gecko powers Firefox. The engine determines how HTML, CSS, and JavaScript actually render — so for layout bugs, the engine matters more than the brand name.

Is my pasted user agent stored?

No. Parsing is processed instantly and never stored — no logs of the strings you check, no analytics on your traffic samples. Log excerpts and UA samples exist only in your current session, so even sensitive production logs can be analyzed without creating a copy.