How to Parse and Read a User Agent String

A User Agent string is the text a browser, app, or bot sends with every HTTP request — e.g., Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/120.0.0.0 Safari/537.36 — that identifies the browser, version, operating system, device type, rendering engine, and whether it is a bot. Reading it by eye is error-prone: Chrome's UA contains "Safari" and "Mozilla" for historical compatibility, Safari's contains "Version," and a single string mixes OS, engine, and browser tokens plus platform details. A User Agent parser that splits the string into structured fields — browser, version, OS, OS version, device type (desktop/mobile/tablet), device brand/model, engine, and bot vs human — makes the data actionable for analytics, debugging, feature support, and bot filtering without hand-written regex.

This expanded A-to-Z guide explains how to parse and read a User Agent string — the anatomy of the UA per MDN: User-Agent and HTTP Semantics (RFC 9110) §10.1.5, how parsing maps tokens to browser/OS/device and handles historical quirks, step-by-step parsing, common UA examples (Chrome, Safari, Firefox, Edge, mobile, bots, curl), the pitfalls of UA sniffing and why feature detection is preferred, the privacy-driven UA reduction and Client Hints, and how to use the parsed data responsibly — with references to MDN, RFC 9110, RFC 9309 (Robots Exclusion), UA Client Hints, and MDN: Browser detection.

What Is a User Agent String?

The User-Agent request header is a free-form string the client sends to identify itself, per HTTP Semantics §10.1.5: User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/120.0.0.0 Safari/537.36. For browsers, it historically starts with Mozilla/5.0 for compatibility with early servers that sniffed for Mozilla, even though the browser is Chrome — this is why every modern browser's UA starts with Mozilla despite not being Firefox. For bots, it is clearer: Mozilla/5.0 (compatible; Googlebot/2.1; +http://www.google.com/bot.html) per RFC 9309. For apps and curl, it is minimal: curl/8.5.0 or MyApp/1.0. The header is optional, can be spoofed, and is being reduced for privacy via Client Hints — but it remains the most available signal for coarse browser/OS/device detection in logs and analytics.

Anatomy — Tokens for Browser, OS, Device, and Engine

Per MDN: User-Agent, a typical desktop Chrome UA has five logical parts:

Mobile adds Mobile and device: Mozilla/5.0 (iPhone; CPU iPhone OS 17_1 like Mac OS X) AppleWebKit/605.1.15 (KHTML, like Gecko) Version/17.1 Mobile/15E148 Safari/604.1 — the parser extracts Browser=Safari 17.1, OS=iOS 17.1 (from CPU iPhone OS 17_1), Device=iPhone, Device Type=Mobile, Engine=WebKit. Android is similar: Mozilla/5.0 (Linux; Android 14; Pixel 8) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/120.0.0.0 Mobile Safari/537.36 → Chrome Mobile 120, Android 14, Pixel 8.

Bot UA is explicit: Mozilla/5.0 (compatible; Googlebot/2.1; +http://www.google.com/bot.html) — the parser flags isBot=true, Bot=Googlebot, Bot Version=2.1, and Bot URL. Other bots: Bingbot, Slurp, DuckDuckBot, facebookexternalhit, Twitterbot.

How to Parse a User Agent String — 3 Steps (With Structured Output)

1. Paste the UA string: From browser dev tools — open console and run navigator.userAgent, or from Network → Headers → User-Agent — or from server logs (access.log), analytics export, or error reports. The UA can be pasted as a single line, even with quotes, and the parser trims it.
2. Parse with historical quirks handled: The parser tokenizes per MDN and HTTP specs, applies a rule set that knows Chrome's UA contains "Safari" and "Mozilla" but is not Safari, that "Version/17.1" is Safari's version (not Chrome's), that "Windows NT 10.0" is Windows 10 (not 10.0), and that "CPU OS 17_1" is iOS 17.1. It maps "Chrome/120.0.0.0" to Browser=Chrome, Major=120, "Windows NT 10.0" to OS=Windows, OS Version=10, and checks bot lists (Googlebot, Bingbot, Slurp, etc.) per RFC 9309 and public bot databases. For Client Hints-aware browsers, it can also parse Sec-CH-UA headers ("Chromium";v="120", "Not_A Brand";v="8") where available.
3. Use structured output: The result is JSON with browser: {name, version, major}, os: {name, version}, device: {type, brand, model}, engine: {name, version}, isBot, botName, raw — ready for analytics (segment by Chrome vs Safari), debugging ("this bug is Safari 17.1 only"), feature support (prefer feature detection, but UA for analytics), or bot filtering (exclude Googlebot from human metrics). The raw UA is kept alongside the parsed fields for auditing.

Common UA Examples — Parsed

Note: Firefox's UA is distinct: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:121.0) Gecko/20100101 Firefox/121.0 — it contains "Gecko" and "Firefox" without "Chrome" or "Safari" (except the leading Mozilla compat). Edge is similar to Chrome but with Edg/120.0.0.0 (note the missing 'e').

Pitfalls — Don't Rely Solely on UA Sniffing (And What to Use Instead)

Per MDN: Browser detection using the user agent, feature detection (if ('fetch' in window) or CSS.supports('display', 'grid')) is preferred over UA sniffing for browser capabilities — UA can be spoofed (extensions and privacy tools alter it), historical quirks mislead (Chrome containing Safari), and new browsers are unknown to old sniffing regex. Use UA parsing for analytics ("what percent of users are on Safari 17?"), debugging ("this bug is Safari 17.1 only"), and bot filtering (exclude Googlebot from human metrics, but verify via reverse DNS per Verifying Googlebot — don't trust UA alone for security).

Privacy and UA reduction: Modern browsers are reducing UA granularity for fingerprinting resistance per UA Client Hints and MDN: User-Agent reduction. Chrome now freezes the UA to Chrome/120.0.0.0 with reduced OS version and introduces Sec-CH-UA headers ("Chromium";v="120", "Not_A Brand";v="8") and Sec-CH-UA-Platform for high-entropy hints — only sent when the server opts in via Accept-CH. The parser handles both the legacy UA string and the newer Client Hints where available, but for coarse analytics the UA string remains the most available signal in logs.

When UA parsing is appropriate:

• Analytics: Segment traffic by browser, OS, and device type — "iOS Safari vs Chrome Mobile conversion rate"
• Debugging: Reproduce a bug reported with a UA string — "this layout breaks on Safari 17.1 on iPhone"
• Bot filtering: Exclude Googlebot, Bingbot, and monitoring bots from human metrics and rate limiting — but verify critical bots via DNS, not just UA
• Not appropriate: Gating a feature on "is Chrome" — use feature detection; blocking a user based on UA — UA is spoofable

FAQs About Parsing User Agent Strings

How do I parse a User Agent string?

Paste the full UA string (from navigator.userAgent in the browser console, or from server logs) into a User Agent parser to get browser, version, OS, device type, engine, and bot status as structured JSON — no regex needed and historical quirks handled per MDN.

Why does Chrome's User Agent contain Safari and Mozilla?

Historical compatibility — Chrome's Blink engine is a fork of WebKit (Safari's engine), which kept Safari and Mozilla tokens so sites that sniffed for "Safari" or "Mozilla" would not block Chrome. The real browser is Chrome when Chrome/120 and Safari/537.36 both appear; Safari is the real browser when Version/17.1 and Safari/604.1 appear without Chrome.

How do I detect bots via User Agent?

Check for bot tokens like Googlebot, Bingbot, Slurp, DuckDuckBot, facebookexternalhit, Twitterbot per RFC 9309 and public bot lists. A parser flags isBot=true and the bot name and URL. For security (e.g., allowing Googlebot through a firewall), don't trust UA alone — verify Googlebot via reverse DNS per Google's verification guide: the IP should reverse to *.googlebot.com.

What is the difference between User Agent and Client Hints?

User-Agent is the legacy single header with the full string; Client Hints are the newer Sec-CH-UA, Sec-CH-UA-Platform, etc., that provide high-entropy details only when the server opts in via Accept-CH, for privacy. Modern Chrome reduces the UA string and prefers Client Hints; the parser handles both where available, but UA remains the most logged signal.

Can User Agent strings be spoofed?

Yes — any client can send any UA string. Browser extensions, privacy tools, and curl with -A can set an arbitrary UA. Treat UA as a hint for analytics, not as authentication for security decisions.

How do I get the User Agent in JavaScript?

In the browser console or code, navigator.userAgent returns the UA string (e.g., Mozilla/5.0 ... Chrome/120 ...). For the newer Client Hints, navigator.userAgentData (where supported) returns structured brands and platform.

Conclusion

Parsing a User Agent string is tokenizing the free-form, historically quirky header into browser, version, OS, device, engine, and bot fields per MDN and HTTP Semantics — with Chrome's Safari token, Safari's Version token, and bot tokens correctly mapped, and with Client Hints as the privacy-preserving successor. A parser that does this instantly turns the raw 100+ character string into actionable structured data for analytics, debugging, and bot filtering — without hand-written regex that breaks on the next browser release.

Paste the next UA string — from dev tools, logs, or analytics — to get browser, OS, device, engine, and bot detection as JSON ready for the log, dashboard, or filter.