User-Agent Parser
Break a User-Agent string down into browser, rendering engine, operating system, device and CPU, and spot bots, crawlers and HTTP clients. Paste a single UA or a whole access log. Parsing runs in your browser.
User-Agent string
Result
Your browserToken breakdown
JSON
Your Client Hints
navigator.userAgentDataReading…
User-Agents or log lines
Summary
Per line
Anatomy of a User-Agent string
A typical desktop Chrome UA looks like Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/130.0.0.0 Safari/537.36. It is a list of product tokens (name/version), each optionally followed by a comment in parentheses. The comment after Mozilla/5.0 describes the platform: OS, version, CPU architecture and, on phones, often the device model. The tokens after it name the engine and the browser.
Very little of it is literally true. Chrome isn't Mozilla, doesn't use KHTML or Gecko, and isn't Safari, but it claims all of them so that old server-side checks treat it as a modern browser. A parser therefore has to check tokens in the right order: Edge and Opera contain Chrome/, Chrome contains Safari/, Android WebView contains both, and almost everything contains Mozilla.
Why every browser says "Mozilla/5.0"
In the 1990s, Netscape Navigator (code-named Mozilla) supported frames and other features that rival browsers lacked, so web servers sent the rich version of a page only to UAs starting with Mozilla. When Internet Explorer added those features, it called itself Mozilla/4.0 (compatible; MSIE 3.0) to get the good pages. Every browser since has done the same. (KHTML, like Gecko) comes from the same history: Safari's WebKit was forked from KDE's KHTML, and it claimed to be "like Gecko" to receive the pages served to Firefox. Chrome, built on WebKit, copied Safari's string, and Edge and Opera, built on Chrome, copied Chrome's.
UA reduction, frozen values and Client Hints
Detailed UA strings are a fingerprinting risk and a source of compatibility bugs, so browsers are freezing them:
- Chrome's UA reduction (rolled out in 2022–2023) sends only the major version (
Chrome/130.0.0.0), always reports Windows asWindows NT 10.0, macOS asMac OS X 10_15_7, and Android asAndroid 10; K, with no device model. - Windows 11 reports
Windows NT 10.0in every major browser, so the UA can't distinguish Windows 10 from 11. - macOS is frozen at 10.15.7 in Safari, Chrome and Edge (Firefox reports 10.15). Apple Silicon Macs still say
Intel Mac OS X, and iPads in desktop mode send a Mac UA. - Firefox fixes the Gecko token at
Gecko/20100101on desktop.
The replacement is User-Agent Client Hints. Chromium browsers send low-entropy hints by default (Sec-CH-UA, Sec-CH-UA-Mobile, Sec-CH-UA-Platform) and expose them to JavaScript as navigator.userAgentData. Detailed values such as the full version, platform version, architecture and model are only sent once the server asks for them with an Accept-CH response header, or in JavaScript via getHighEntropyValues(). Checking whether platformVersion is 13 or higher is the supported way to detect Windows 11. Firefox and Safari don't implement Client Hints, so for them the UA string is all you get.
Feature detection beats UA sniffing
If you want to know whether a browser supports something, test for it directly: 'share' in navigator, CSS.supports('display', 'grid'), or @supports in CSS. UA checks break when a new browser version ships, when a browser you didn't list (Brave, Arc, a WebView) copies Chrome's UA, or when a user or extension spoofs the string. Use UA parsing for analytics, logging, debugging and bot handling, where an approximate answer is fine, not for deciding which code to run.
Using User-Agents in log analysis
UAs are most useful in access logs: they show which browsers you need to support, how much traffic is mobile, and how much is bots. Bulk mode extracts the UA from common log formats:
- nginx / Apache combined: the last quoted field, after the referrer.
- AWS Application Load Balancer: the quoted
user_agentfield right after the quoted request line. Health checks don't appear in ALB access logs, but they do reach your targets with the UAELB-HealthChecker/2.0, so filter them out of application logs. - Amazon CloudFront: standard logs are tab-separated, and the
cs(User-Agent)field is URL-encoded (%20for spaces). Bulk mode decodes it. To vary cached content by device, use CloudFront'sCloudFront-Is-Mobile-Viewerand related headers rather than forwarding the fullUser-Agent, which would split your cache into thousands of variants. When CloudFront doesn't forward the viewer's UA, your origin seesAmazon CloudFrontinstead. - JSON logs (API Gateway access logs, app logs): any field named like
userAgentorhttp_user_agent.
Treat bot names with caution: anyone can send Googlebot in a UA. To verify a crawler, do a reverse DNS lookup on the IP and check that it resolves back to the crawler's domain, or compare against the IP ranges the operator publishes. Google, Bing, OpenAI and Anthropic all publish theirs.