User Agent Parser
See what a User-Agent string claims: browser, engine, operating system and device, which parts modern browsers freeze, and whether it is a crawler, AI bot, scanner or script. Everything runs in your browser.
Common User Agents
What this tool does
This parses a raw HTTP User-Agent header into its components — browser and version, operating system and version, device type, and whether the string looks like a known bot — and flags it. Parsing runs entirely in your browser; the string you paste is never sent to a server.
How to use it
- Paste a User-Agent string, or press Use My UA to parse your own browser’s.
- Press Parse to see the breakdown, or click a sample under Common User Agents to try a real Chrome, Safari, Firefox, Googlebot or curl string.
- Check Raw Components to see the individual tokens the parser matched, useful when a string is unusual or looks spoofed and you want to see exactly what it claims.
Since 2022–2023 Chrome and other Chromium browsers send a reduced User-Agent: the version is always NNN.0.0.0 and the platform part is one of a few fixed values (for example Windows NT 10.0; Win64; x64 or Linux; Android 10; K), so the real OS version and phone model are not in the string. The parser flags these and says which values are frozen. Results were checked against an independent parser (ua-parser-js) on the User-Agent strings published by MDN, Chromium, Google, Microsoft, Apple, Samsung, OpenAI and Perplexity.
Typical uses: debugging why a page renders differently for one visitor, checking whether traffic in a log file is a real browser or an automated client, and verifying that a custom or embedded client’s User-Agent string is well-formed before shipping it.
Frequently asked questions
Can a User-Agent string be trusted or is it easily spoofed?
It cannot be trusted for anything security-sensitive. The User-Agent header is just a string the client chooses to send; browser extensions, developer tools, curl and scripts can set it to anything. Use it for analytics and compatibility hints, never as an access control or authentication signal.
Why does every modern browser's User-Agent contain "Mozilla" and "like Gecko"?
It is historical baggage, not a lie about the engine. Early sites checked for the literal substring Mozilla to decide whether a browser supported frames, so every later browser — Chrome, Safari, Edge — kept it in for compatibility. KHTML, like Gecko exists for the same reason: WebKit-based browsers added it so Gecko-sniffing sites would treat them as capable.
How do bot detection heuristics in a User-Agent parser actually work?
Mostly pattern matching against known bot signatures (bot, crawler, spider, or specific strings like Googlebot) plus checking for the absence of fields a real browser always sends. It is a heuristic, not proof: a well-behaved crawler self-identifies honestly, but nothing stops a scraper from copying a real browser’s User-Agent verbatim to blend in.
What are User-Agent Client Hints, and are they replacing this string?
Client Hints (Sec-CH-UA, Sec-CH-UA-Platform, Sec-CH-UA-Mobile, and more behind an opt-in request) are a newer, structured alternative that Chromium-based browsers already send. The idea is to reduce passive fingerprinting: the browser exposes only coarse information by default and reveals detail like the full OS version only if the site explicitly asks. The classic User-Agent header still exists in parallel and is not going away for now.
Why do desktop-class browsers on tablets sometimes report as "Mobile"?
The Mobile token and screen-size heuristics are what most responsive sites key off, not the actual form factor. Some tablets and foldables send a desktop-like string on purpose to get the desktop layout, while others keep Mobile for the mobile layout; device detection from the User-Agent alone is always an approximation, not a hardware fact.