User Agent Parser

The Kordu User Agent Parser decodes any User-Agent HTTP header string into human-readable components: browser name and version, operating system and version, device type (desktop, mobile, tablet, or bot), and rendering engine (Blink, WebKit, Gecko, Trident). Paste a UA string from server logs, analytics exports, or a debugging session, or click "Use my browser" to populate the input with navigator.userAgent from your current browser.

What a User-Agent string is

The User-Agent header is defined in RFC 7231 (originally RFC 1945 for HTTP/1.0) as a free-form product token that identifies the client software making an HTTP request. Every browser, crawler, HTTP library, and CLI tool sends one with every request, and servers routinely log it alongside the request method, path, status, and referrer. In theory it is a simple Product/Version list. In practice it is one of the messiest strings on the web — the result of thirty years of compatibility workarounds stacked on top of each other.

Anatomy of a modern UA string

Almost every desktop and mobile browser ships a UA that starts with Mozilla/5.0 — a lie inherited from the browser wars, where servers used to gate features on the Mozilla token, forcing every competitor to claim to be Mozilla. A typical modern Chrome UA looks like:

Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/124.0.0.0 Safari/537.36

That string breaks down into five pieces:

• Mozilla/5.0 — the legacy compatibility prefix.
• (Windows NT 10.0; Win64; x64) — the platform token (OS + CPU).
• AppleWebKit/537.36 (KHTML, like Gecko) — a WebKit compatibility claim carried over from when WebKit forked from KHTML; Chrome still reports it even though Chrome now uses Blink.
• Chrome/124.0.0.0 — the real browser token and version.
• Safari/537.36 — another compatibility token, left in so Safari-only code paths on legacy servers do not exclude Chrome.

Rendering engines

Four engines power virtually every browser in production. Blink powers Chrome, Edge, Opera, Brave, Vivaldi, Samsung Internet, and every other Chromium fork. WebKit powers Safari on macOS and iOS, and — because of Apple's App Store rules — every browser on iOS, including Chrome (CriOS), Firefox (FxiOS), and Edge (EdgiOS). Gecko powers Firefox and its forks (LibreWolf, Tor Browser). Trident was the engine for legacy Internet Explorer and now appears only in ancient log entries. Knowing which engine renders a request is often more useful than knowing the browser name, because rendering bugs track engine versions, not browser brands.

Device detection heuristics

Device type is not a formal field — parsers infer it from substrings inside the platform token and elsewhere in the UA. Mobile typically marks a phone. Tablet, iPad, or specific Android tablet tokens mark tablets. iPadOS 13+ famously reports itself as macOS Safari by default to stop sites from serving the phone layout, so iPad detection also checks for a touch-screen hint. Bots and crawlers usually self-identify with bot, crawler, spider, or a branded token such as Googlebot, Bingbot, Slurp (Yahoo), DuckDuckBot, YandexBot, Baiduspider, AhrefsBot, SemrushBot, GPTBot (OpenAI), ClaudeBot (Anthropic), PerplexityBot, Google-Extended, and CCBot (Common Crawl). AI crawler traffic has grown fast over the last two years, and most well-behaved AI crawlers respect robots.txt — but only if you know which token to list.

Spoofing and its limits

Any user can change their UA — browsers ship a dev-tools option, curl and wget have -A, and every HTTP library exposes a header setter. That makes UA-based bot blocking trivially bypassable on its own. Serious bot detection layers TLS fingerprinting (JA3, JA4), HTTP/2 fingerprinting, browser feature probing, and behavioral signals on top of the UA header. For fraud and abuse work, treat the UA as a helpful hint, never as a trusted identity.

Client Hints and User-Agent Reduction

Chrome has been slowly freezing and reducing the UA since Chrome 101 as part of the User-Agent Reduction initiative. The reduced UA exposes a minor version of 0.0.0 and a generic platform token; the precise browser, version, mobile flag, and platform details move into the new Sec-CH-UA, Sec-CH-UA-Mobile, and Sec-CH-UA-Platform headers (User- Agent Client Hints). Sites that need the full detail opt in with the Accept-CH response header or the Permissions-Policy: ch-ua-* policy. Firefox and Safari have not shipped Client Hints, so the classic UA header will stay in server logs for years. A good parser has to handle both worlds.

Privacy implications

The UA string is a large piece of the browser fingerprinting surface — EFF's Panopticlick work showed that UA, language, installed fonts, and screen resolution are usually enough to identify a browser uniquely. Reducing the UA is one of several anti-fingerprinting changes Chromium has made; Safari ITP and Firefox's resistFingerprinting mode cap UA entropy as well. Running your own UA through this parser is the quickest way to see what every site you visit already knows about your browser.

When to use a UA parser — and when not to

Good use cases: analyzing access logs and CDN logs, segmenting analytics by browser or engine, detecting and rate-limiting self-identified bots, reproducing user-reported bugs, and building internal debug dashboards. Bad use cases: branching UI or features on browser name. Feature detection (if ("clipboard" in navigator), @supports, progressive enhancement) is more reliable, survives engine swaps, and does not break when Chromium forks update their UAs. Never serve different HTML to mobile UAs — Google's mobile-first index penalizes UA-based content swaps, and responsive CSS with @media is the right tool.

Comparison to other UA parsers

The most widely used library is UA-Parser-JS (MIT, ~16k stars), which powers analytics dashboards across the web. Server-side stacks often use ua-parser (Python), woothee, or device-detector. This tool gives you the same core output — browser, OS, device, engine — for ad-hoc UA inspection without installing anything, wiring up an API, or pasting strings into a random web form that may log your data.

Privacy

All parsing runs client-side in your browser. The UA string never leaves your device. There is no backend, no logging, and no analytics tied to the parse.