What a User-Agent String Is
Every HTTP request your browser sends includes a header called User-Agent: a self-identifying string that tells the server what software is making the request. It looks like a small explosion of historical baggage — Mozilla/5.0 (Macintosh; Intel Mac OS X 14_5) AppleWebKit/605.1.15 (KHTML, like Gecko) Version/17.5 Safari/605.1.15 — and it's how websites do analytics, decide which CSS prefixes to send, classify bots, and make a thousand small "is this Chrome or Firefox" decisions per page load.
The User Agent Parser breaks that string apart into structured fields: browser, rendering engine, operating system, device, CPU. The default loads your current browser's UA, so you immediately see what your site sees about you.
How the Microapp User Agent Parser Works
By default, your browser's navigator.userAgent is loaded and parsed. To inspect a different UA, paste any string into the textarea — server logs, analytics exports, anywhere you've copied a UA from. The parser breaks the string into 5 fields: Browser (Chrome, Firefox, Safari…), Engine (Blink, Gecko, WebKit…), OS (Windows, macOS, iOS, Android, Linux…), Device (vendor + model + type when applicable), and CPU (architecture).
The four sample buttons (iPhone Safari, Chrome Win, Firefox Mac, Googlebot) load known-good UAs so you can see what each shape looks like decoded. Parsing runs locally via the ua-parser-js library — the same library used by GitHub, Slack, and many analytics platforms. Nothing is uploaded.
Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; Googlebot/2.1; +http://www.google.com/bot.html) Chrome/W.X.Y.Z Safari/537.36. The parser identifies Browser as Googlebot, Engine as WebKit, and leaves Device empty — exactly how you'd want to filter it from human traffic in your analytics.
Why User-Agent Strings Are So Weird
Pure historical baggage. The Mozilla/5.0 prefix dates from the 1990s, when websites only served the fancy version of their content to Netscape (codenamed "Mozilla"); every browser added "Mozilla/5.0" to fool the version check. (KHTML, like Gecko) is from when Apple's WebKit pretended to be the KDE rendering engine, which itself pretended to be Firefox's Gecko engine. Each generation of browser carries the previous generation's lies forward because so much code on the web parses UAs with brittle string matching that anything else breaks pages.
This is the User-Agent string equivalent of carrying around your great-grandparents' debt: nobody alive remembers signing up for it, but you're stuck paying it.
Browser vs Engine vs OS vs Device — What Each Means
Browser is the user-facing app: Chrome, Firefox, Safari, Edge, Opera. What you double-click in the dock. Engine is the underlying rendering library: Blink (Chrome, Edge, Opera, Brave, Vivaldi — they all use the same engine), Gecko (Firefox), WebKit (Safari and all iOS browsers because Apple requires it). Engine matters more for compatibility quirks than browser brand — fixing a "broken in Chrome" bug usually fixes it in Edge, Opera, and Brave too.
OS is the operating system. Device is the vendor + model when the UA includes them — desktop UAs often leave this blank because "Macintosh" or "Windows NT 10.0" describes the OS, not the hardware. Mobile UAs include "iPhone" or "Pixel 8" so Device fills in. CPU is the architecture (amd64, arm64) when present.
Should You Detect Browsers This Way?
Mostly no. UA detection is the lazy default but it's brittle: browsers can lie (devs override their UA all the time, "request desktop site" toggles change it), bots can spoof (Googlebot identifies itself, but malicious crawlers don't), and the strings change with every browser version, breaking your detection code.
For features, use feature detection instead: if (navigator.share) { ... } tests whether the Web Share API exists, regardless of browser. if (CSS.supports('display: grid')) { ... } tests grid support directly. Feature detection gives you the right answer even on browsers that didn't exist when you wrote the code.
For analytics, UA parsing is fine — knowing 30% of your visitors are on iOS Safari is useful for prioritizing testing. For security or feature gating, never trust UA alone.
What's User-Agent Client Hints?
A modern alternative Google is pushing. Instead of one giant string the server has to parse, the browser sends structured headers: Sec-CH-UA, Sec-CH-UA-Platform, Sec-CH-UA-Mobile, Sec-CH-UA-Full-Version-List. Less spoofable, less fingerprintable, easier to parse. Chrome already sends them; Safari and Firefox have partial support.
UA parsers will eventually pivot to Client Hints. For now, the full UA string remains the default for backwards compatibility — every server in the world parses it.
Common Pitfalls
Treating Edge as Chrome. They share the Blink engine but have different UAs and different feature sets in some areas. UA parsers handle this correctly; naive substring matching for "Chrome" catches Edge too.
Treating all "Safari" as Apple. Many in-app browsers on iOS (Twitter, Instagram, LinkedIn) use WebKit but identify with custom UAs that include "Safari" because they're WKWebView. The parser distinguishes them; substring matching doesn't.
Trusting bot identification. Honest bots (Googlebot, Bingbot, Slackbot) identify themselves clearly. Malicious crawlers spoof a Chrome UA. Don't filter spam by UA alone — combine with rate limiting, IP reputation, and behavior signals.
Overdetecting mobile. Phones sometimes have UAs that look like tablets, tablets sometimes look like desktops with touch. Use CSS media queries (@media (pointer: coarse)) for touch-vs-mouse decisions, not UA parsing.
Related Tools
For testing the URL portion of HTTP requests, use the URL Encoder/Decoder. To build cURL commands that include custom UA strings, see the cURL Builder. To generate fake IP addresses for test fixtures (often used alongside fake UAs), the Random IP Generator is the right tool. To inspect or build JSON returned from APIs, the JSON Formatter is the right choice.