Online User-Agent Parser: Identify Browser and Device Information

What Is User-Agent Parsing

User-Agent parsing turns the browser's User-Agent string into structured fields (browser, rendering engine, operating system, device type, CPU architecture, and more). On ToolVault the parse runs entirely in your browser — the string is never uploaded.

User-Agent String Structure

Mozilla/5.0 (iPhone; CPU iPhone OS 16_0 like Mac OS X)
AppleWebKit/605.1.15 (KHTML, like Gecko)
Version/16.0 Mobile/15E148 Safari/604.1
│           │                    │        │
│           │                    │        └─ Browser version
│           │                    └─ Browser name
│           └─ Operating system
└─ Engine version

Parsed Result Example (aligned with the tool JSON)

For the iPhone Safari UA above, the tool's "Copy JSON" output looks roughly like this:

{
  "raw": "Mozilla/5.0 (iPhone; …) Version/16.0 Mobile/15E148 Safari/604.1",
  "browser": { "name": "Safari", "version": "16.0", "major": "16" },
  "engine": { "name": "WebKit", "version": "605.1.15" },
  "os": { "name": "iOS", "version": "16.0" },
  "device": { "type": "mobile", "vendor": "Apple", "model": "iPhone" },
  "cpu": {},
  "isBot": false,
  "isMobile": true,
  "isTablet": false,
  "isDesktop": false,
  "isReducedUA": false
}

Desktop Chromium UAs often also populate cpu.architecture (for example x86_64). When a freeze pattern matches, isReducedUA is true.

Why You Need User-Agent Parsing

1. Analytics: browser-family and device mix (prefer parsed fields over raw strings)
2. Compatibility testing: spot legacy or odd clients before you ship a workaround
3. Traffic hygiene: signature-level filters for HeadlessChrome, curl, python-requests
4. Security analysis: compare spoofed or unusual User-Agents with other request signals
5. Responsive / SEO assist: device type is a hint only — gate features with feature detection, not UA sniffing

How to Use the Online Tool

Open the User-Agent Parser:

1. Paste a full UA, or click Detect My UA
2. Use the example library for desktop / mobile / tablet / reduced UA / bot samples (WeChat, Samsung Internet, Reduced Chrome, Googlebot, HeadlessChrome, curl)
3. Read browser, engine, OS, device, CPU architecture, and category badges
4. A Reduced / Frozen UA badge means Chromium-style minor versions are not trustworthy
5. Copy JSON in one click

The amber callout on the page states the hard boundary: UA string only — no Sec-CH-UA.

How to Read the Fields

UA-CH (Client Hints): the capability boundary

Chromium's User-Agent Reduction freezes minor versions in the string and moves real capability reporting to Sec-CH-UA, Sec-CH-UA-Platform, Sec-CH-UA-Mobile, and related headers. High-entropy values (full version, architecture, model) require an Accept-CH negotiation on the server.

What that means for this tool:

• In scope: heuristic parse of a pasted UA; flag freeze patterns, engine and architecture tokens, common bot signatures
• Out of scope: reading or simulating Client Hints; recovering true minor versions or exact models from a frozen string
• Server migration checklist: merge both sources (prefer CH, fall back to UA); store browser family / OS family / bot y/n for analytics; treat raw UAs as personal data with a retention policy

A frozen string is not a parser bug — it is deliberate entropy reduction. The three "Chrome reduced" samples in the example library exist so you can see that shape side by side with a full build.

Parsing for bot detection: the three-layer heuristic

1. Signature matching — HeadlessChrome, python-requests, curl, Go-http-client: catches naive bots
2. Inconsistency detection — UA claims mobile iOS without a version token, or UA disagrees with Sec-CH-UA-Platform: catches half-updated spoofs (layer two needs CH; this tool cannot do it alone)
3. Behavioral — rate, header order, TCP fingerprint: needs infrastructure

Honest boundary: string-level tooling mainly covers layer one and surfaces fields you can compare elsewhere. Claiming to catch every bot from the UA alone overpromises.

Privacy: what a UA string actually reveals

A full UA (browser version, OS version, Android model) is a fingerprint fragment. Parsing hygiene: log the fields you need; strip device model from analytics; if you store raw UAs, GDPR-style retention applies. The parser running locally is the privacy-clean pattern — nothing uploaded because nothing needs to be.

Using the parser in day-to-day debugging

Typical workflows where a local User-Agent Parser saves a round trip to production logs:

1. Support ticket — customer pasted a UA; you need browser family and OS before asking for a screenshot
2. CDN / WAF rule dry-run — confirm which tokens your bot rule would match before shipping the rule
3. Analytics sanity check — compare a “Chrome reduced” sample to a full desktop UA so dashboards do not treat freeze patterns as unknown browsers
4. SSR vs client — verify the UA your edge injects matches what the browser later sends (mismatches show up as hydration or targeting bugs)

Paste from the example library when you need a known shape (mobile Safari, reduced Chrome, curl). Clear the field and paste a live UA when diagnosing a real report. Parsing stays in the browser — useful when the string itself is treated as personal data.

What to store after you parse

Prefer derived fields over raw strings in long-lived analytics:

That mapping matches how Client Hints encourage low-entropy defaults: keep what you need for product decisions, discard the fingerprint residue.

FAQ

Will User-Agent Strings Be Deprecated?

Chrome is rolling out User-Agent Reduction: the string remains, but it carries less detail. Treat Client Hints as the capability source and the UA as a legacy compatibility field.

How to Detect Bots and Crawlers?

Start with signature keywords and the bot samples in the example library. Determined crawlers spoof UAs, so combine with request rate, behavior, and URL parameter context.

How to Distinguish Mobile vs Desktop?

UA tokens such as Mobile / iPhone / Android are a starting point; add viewport width and touch capability. Never treat a single UA check as the only truth.

Why Does Windows Show as "Windows 10/11"?

Both still advertise Windows NT 10.0 in classic UAs. Splitting 10 from 11 needs Client Hints or another signal — string parsing alone cannot do it reliably.

Triage notes

Every row of the field table carries its common trap, and most of them are the UA ecosystem's historical debt: Windows 10 and 11 both report NT 10.0, so the honest label is Windows 10/11; Edge's UA still carries Chrome/, so match by specificity first. The frozen-UA paragraph says something that matters: a frozen string is not the parser breaking, it is the ecosystem deliberately lowering entropy — the three Chrome 'reduced' samples in the example library exist to let you see the phenomenon side by side. Boundary statements run through the whole article: it parses the UA string only and reads no Client Hints, and of the three-layer bot-detection heuristic the string layer covers only the first — claiming 'UA alone catches all bots' is over-promising.

From the ToolVault developer notebook. The homepage collects more browser-local tools.