User-Agent Parser

The User-Agent Parser extracts browser name, version, rendering engine, operating system, and device type from User-Agent header strings, decoding the notoriously convoluted format that has accumulated decades of compatibility tokens. Paste a string like Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/120.0.0.0 Safari/537.36 and get a clear breakdown: Chrome 120.0, Blink engine, Windows 10, Desktop.

Understanding User-Agent Strings

The User-Agent header is one of the oldest and most misunderstood parts of HTTP. It was originally designed as a simple identifier -- a way for a browser to tell the server its name and version so the server could tailor its response. Netscape Navigator sent Mozilla/1.0, and that was that. But decades of browser wars, compatibility hacks, and feature detection have turned the User-Agent string into a tangled mess of historical tokens that tell you far more about the history of web browsers than about the actual client making the request.

The problem started when Internet Explorer wanted to receive the same content that servers were sending to Netscape Navigator. So IE claimed to be "Mozilla compatible." Then Firefox came along as the true successor to Mozilla and used the same prefix. Safari added "like Gecko" so servers that checked for Gecko would serve it modern content. Chrome copied Safari's entire string and added its own token. Edge copied Chrome's string and added yet another token. The result is that today's Chrome User-Agent contains "Mozilla," "AppleWebKit," "KHTML," "Gecko," "Chrome," and "Safari" -- and it is none of those things except Chrome.

For developers and system administrators, User-Agent parsing is still necessary despite its quirks. Access log analysis requires knowing which browsers and operating systems your users run. Bot detection depends on identifying crawlers like Googlebot and Bingbot. Browser-specific bug reports need the exact version to reproduce. And traffic analysis requires distinguishing mobile from desktop users. This parser cuts through the historical noise and extracts the information that actually matters: what browser, what version, what OS, and what device type.

How to Parse a User-Agent String

1. Paste a User-Agent string into the input field (from access logs, browser DevTools, or HTTP headers).
2. Click Parse to extract all identifiable components.
3. Review the parsed results: browser family, version, engine, OS, device type, and bot detection.

User-Agent Parsing Examples

When to Use the User-Agent Parser

• Analyzing server access logs -- Parse User-Agent strings from web server logs to understand your traffic breakdown by browser, OS, and device type.
• Identifying bot traffic -- Detect known crawlers (Googlebot, Bingbot, Baiduspider) and distinguish them from human traffic in analytics.
• Debugging browser-specific issues -- Extract the exact browser version and rendering engine from a bug report's User-Agent to reproduce issues.
• Testing browser detection logic -- Validate that your server-side or client-side browser detection code correctly identifies various User-Agent patterns.
• Understanding traffic patterns -- Determine the mobile vs. desktop ratio and which OS versions your users run to inform testing priorities.
• Security log analysis -- Identify suspicious User-Agent strings in access logs that may indicate automated attacks or scraping.

Why User-Agent Strings Are So Confusing

The History of Browser Spoofing

Every modern browser starts its User-Agent with Mozilla/5.0 due to a chain of historical compatibility hacks:

1. Netscape Navigator (the original Mozilla) was the first browser to introduce the User-Agent header and used Mozilla/version.
2. Internet Explorer claimed to be Mozilla/4.0 (compatible; MSIE...) so servers that checked for "Mozilla" would send it the same rich content.
3. Firefox used Mozilla/5.0... Gecko/... as the successor to Netscape.
4. Safari added (KHTML, like Gecko) so servers that looked for "Gecko" would send modern content.
5. Chrome copied Safari's token and added its own, resulting in a string that claims to be Mozilla, like KHTML, like Gecko, Chrome, and Safari simultaneously.
6. Edge (Chromium-based) added Edg/ to Chrome's already lengthy string.

What Each Token Actually Means

In a typical Chrome 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

• Mozilla/5.0 -- Historical compatibility token (meaningless today)
• Windows NT 10.0; Win64; x64 -- Operating system and architecture
• AppleWebKit/537.36 -- Rendering engine version (frozen value in Chromium)
• KHTML, like Gecko -- Compatibility claim
• Chrome/120.0.0.0 -- The actual browser and version
• Safari/537.36 -- Another compatibility token (Chrome is not Safari)

Client Hints: The Modern Alternative

User-Agent Client Hints (Sec-CH-UA-* headers) are the modern replacement, providing structured, low-entropy data:

Sec-CH-UA: "Chromium";v="120", "Google Chrome";v="120"
Sec-CH-UA-Mobile: ?0
Sec-CH-UA-Platform: "Windows"

The parser recognizes both legacy User-Agent strings and modern Client Hints values.

Windows Version Mapping

Windows versions in User-Agent strings use internal NT version numbers that do not match marketing names:

Note that Windows 10 and Windows 11 share the same Windows NT 10.0 value. Distinguishing them requires User-Agent Client Hints (Sec-CH-UA-Platform-Version).

Practical Tips for User-Agent Analysis

When analyzing access logs, do not try to parse User-Agent strings with regular expressions. The format is too irregular and has too many variations to handle reliably with regex. Use a dedicated parsing library like ua-parser-js (JavaScript), user-agents (Python), or browscap (PHP). These libraries maintain databases of known patterns and are updated as new browsers and versions are released.

For bot detection, remember that legitimate bots typically identify themselves clearly in their User-Agent strings, but malicious bots almost always spoof real browser strings. If you see a User-Agent claiming to be Chrome 120 on Windows 10 but the request comes from a data center IP address, makes 100 requests per second, and ignores robots.txt, it is almost certainly a bot regardless of what the User-Agent says. Effective bot detection combines User-Agent analysis with behavioral signals like request rate, IP reputation, and JavaScript execution capabilities.

The trend in the browser ecosystem is to reduce the information in User-Agent strings. Chrome has been gradually freezing parts of its User-Agent (the WebKit version is frozen at 537.36, the Chrome minor version is always .0.0.0) and pushing developers toward Client Hints for detailed information. If you are building new systems that need browser or OS information, consider supporting Client Hints from the start rather than relying solely on traditional User-Agent parsing, as the amount of useful information in the User-Agent string will only decrease over time.

Frequently Asked Questions

How can I tell the difference between Chrome and Edge?

Chromium-based Edge includes an Edg/ token (note: not "Edge") at the end of its User-Agent string. Both share the same Chrome/ and Safari/ tokens. Look specifically for Edg/ to distinguish Edge from Chrome.

Is it reliable to detect device type from the User-Agent?

For broad categories (mobile vs. desktop), User-Agent detection is reasonably reliable. The presence of Mobile in the string indicates a mobile device. However, tablet detection is less consistent, and some mobile browsers in "desktop mode" send desktop-style User-Agent strings. For more reliable detection, combine User-Agent parsing with responsive design techniques.

How do I detect bots and crawlers?

Legitimate bots typically identify themselves clearly: Googlebot, bingbot, Baiduspider, YandexBot, DuckDuckBot. The parser maintains a list of known bot identifiers. However, malicious bots often spoof real browser User-Agent strings, so User-Agent alone is not sufficient for security-critical bot detection.

Why does Chrome report "Safari" in its User-Agent?

Chrome includes Safari/537.36 for historical compatibility. When Chrome first launched, many websites checked for "Safari" to serve WebKit-compatible content. Chrome inherited WebKit (later forking it into Blink) and kept the Safari token to avoid being served degraded content. It is purely a compatibility artifact and does not mean Chrome is related to Safari.

What is the "reduced User-Agent" initiative?

Starting with Chrome 110, Google has been gradually reducing the information in Chrome's User-Agent string as part of the Privacy Sandbox initiative. The goal is to minimize passive fingerprinting by freezing or removing granular version numbers, OS details, and device model information. Developers who need this information are encouraged to use User-Agent Client Hints instead, which require an explicit server opt-in and are more privacy-preserving.

Can I trust the OS version in a User-Agent string?

Generally yes for identifying the OS family (Windows, macOS, Linux, iOS, Android), but the specific version may be frozen or inaccurate. Chrome on Windows reports Windows NT 10.0 for both Windows 10 and Windows 11. Chrome on macOS may freeze the version at a specific value. For precise OS version detection, use Client Hints or server-side detection methods.

Related Tools

• HTTP Header Formatter - Parse and format HTTP request headers including User-Agent
• Cookie Header Parser - Parse cookies sent alongside User-Agent in requests
• curl Command Builder - Build curl commands with custom User-Agent headers for testing
• HTTP Status Code Lookup - Look up status codes returned to different User-Agents
• CORS Header Explainer - Understand CORS behavior across different browsers