User Agent Parser

The "Mozilla/5.0" prefix on every modern browser dates to the late 1990s — sites checked UA for "Mozilla" to send the modern HTML version instead of basic markup. Every competing browser learned to claim Mozilla compatibility. Then sites checked for specific Mozilla products, so browsers claimed those too. Chrome's UA today says it is Mozilla, like Gecko, like Safari, AND Chrome. None of those are individually true; the cascading claims are a historical fossil.

Browsers have been moving away from UA. Chrome ships User-Agent Client Hints (UA-CH) — a structured header set replacing the freeform UA. UA-CH provides Sec-CH-UA, Sec-CH-UA-Mobile, Sec-CH-UA-Platform with explicit fields. Parse those instead when the client supports them; fall back to UA parsing otherwise.

• Browser family — Chrome, Firefox, Safari, Edge, Opera, Brave, Vivaldi, Samsung Internet, etc. ~30 distinct families in active use 2026.
• Version — major.minor.patch. Most modern browsers report only major; minor/patch typically zeroed for fingerprint reduction.
• Engine — Blink (Chrome/Edge/Opera), Gecko (Firefox), WebKit (Safari). All three converge on web standards; engine still matters for CSS/JS quirks.
• OS family and version — Windows, macOS, Linux, iOS, Android, Chrome OS. Version reporting varies in granularity.
• Device class — desktop, mobile, tablet, console (PS5, Xbox), TV. Inferred from UA hints and screen-size signals where available.
• Bot detection — Googlebot, Bingbot, Slackbot, social-preview crawlers (Facebookexternalhit, Twitterbot), and known scrapers. Bots that try to look like Chrome require behavioral signals, not UA inspection.

• Analytics — segmenting users by browser/OS for reporting is fine. The UA is approximate; analytics tolerate noise.
• Bot vs human detection — partial. Many bots send legitimate UAs; many humans send unusual UAs. Pair UA with CAPTCHA or behavior.
• Logging and debugging — recording UA helps reproduce client-side bugs ("only happens on iOS Safari 17 in private mode").
• Compatibility shimming — for known-broken-on-X behavior, UA branching can be appropriate. Prefer feature detection (`if ("flexbox" in style)`) where possible.

• Feature detection — never use UA to decide "can the browser do X". Use `typeof X === "function"` or `"X" in object`. Browsers misreport, users spoof, and UA is brittle.
• Security decisions — UA can be set to anything by curl or any HTTP client. Authentication, rate limiting, abuse prevention should not depend on UA matching any pattern.
• Mobile detection for layout — use CSS media queries (`@media (max-width: 768px)`) or container queries. UA-based mobile detection misses tablets in landscape, foldables, large phones, small laptops.
• Cookie / consent gates — UA spoofing trivially bypasses. Use behavioral and IP-based signals where stakes are high.

• You are reading server logs and want to know what kind of client generated a specific request.
• You are debugging "this user-agent breaks our flow" — paste the UA, see what it parses as, decide whether it is a real client or a bot.
• You are auditing what UA strings your site receives and want to bucket them by browser/OS/version for compatibility decisions.
• You are testing your analytics or bot-detection logic with sample UAs and want to verify each parses correctly.

• It will not detect spoofed UAs. A curl request with `--user-agent "Chrome/124"` parses as Chrome 124 — there is no signal in the UA itself that says "fake". Behavioral fingerprinting (TLS fingerprint, header order, timing) detects spoofers; UA parsing alone cannot.
• It will not perfectly identify every bot. Hundreds of crawlers and scrapers exist; new ones daily. Coverage is "most common" not "all".
• It will not parse UA-CH. The structured Client Hints headers (Sec-CH-UA, Sec-CH-UA-Platform) are the new standard and require separate parsing logic from your server-side code.