User-Agent strings in 2026: parsing, Client Hints, and privacy

Why UA strings look insane

A typical modern Chrome User-Agent:

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

This one string claims to be:

• Mozilla/5.0 — Netscape (1996)
• AppleWebKit/537.36 — Safari's engine (2003)
• KHTML — Konqueror's engine (1998)
• like Gecko — Firefox's engine
• Chrome/125.0.0.0 — the actual browser
• Safari/537.36 — again claiming Safari

Every major browser lies in its UA string, layered on top of the last lie, because sites sniffing UAs would block "unknown" browsers. Chrome pretended to be Safari to bypass Safari sniffers. Edge pretended to be Chrome. Firefox pretended to be Netscape 5. Now every browser inherits every lie.

Parsing the modern soup

The reliable parts of a modern UA:

• The last Browser/Version token usually names the actual browser. Chrome/125, Edg/125, Firefox/128, Safari/17.
• The parenthetical section describes the platform. (Windows NT 10.0), (Macintosh; Intel Mac OS X 10_15_7), (iPhone; CPU iPhone OS 17_5).
• The rendering engine — AppleWebKit, Gecko, Trident (dead) — usually appears before the browser token.

The order of tokens matters. Edge appears at the end (Edg/125) after Chrome; missing that suffix means the parser thinks Edge is Chrome. User-Agent Parser handles the ordering correctly — it identifies Edge before matching Chrome.

What you can and can't infer

Reliable:

• Browser family (Chrome, Firefox, Safari) — usually correct.
• OS family (Windows, macOS, Linux, iOS, Android) — usually correct.
• Whether it's mobile — the Mobile token in the UA is reliable enough for layout decisions.

Unreliable:

• Exact version numbers. All Chromium browsers now freeze the major version at "Chrome/109" or use Client Hints for the real version. Reading Chrome/xxx from UA doesn't give you the current version.
• Device model. Some Android devices include it (SM-G991B), Apple devices don't (iPhone is all you get).
• Bot detection. Every serious bot spoofs a real browser UA. UA sniffing catches only lazy scrapers.

Client Hints — the real successor

Chromium browsers now send Client Hints — a set of HTTP headers that carry structured versions of what the UA string tried to convey:

• Sec-CH-UA: "Chromium";v="125", "Not:A-Brand";v="24"
• Sec-CH-UA-Mobile: ?0
• Sec-CH-UA-Platform: "Windows"

You get more with high-entropy hints (opt-in via response header):

• Sec-CH-UA-Platform-Version
• Sec-CH-UA-Full-Version-List
• Sec-CH-UA-Model
• Sec-CH-UA-Arch

For anything server-side that needs accurate client info in 2026, prefer Client Hints over the UA string. Every Chromium browser sends them; Firefox and Safari don't (yet — Safari has said no).

The three legitimate use cases for UA

Despite the mess, UA sniffing still has real uses:

1. Analytics. You need "% of visitors on mobile" and "which browsers we support." Aggregate stats where individual accuracy doesn't matter.

2. Content negotiation. Serving WebP to browsers that support it (via UA or Accept header — prefer Accept).

3. Bug reports. "Report a bug" forms benefit from including the parsed UA — helps you reproduce the environment.

Where UA sniffing is the wrong tool

Feature detection. Always prefer if (typeof x !== "undefined") over "if it's Chrome, use X." Browsers ship the same feature at different times; UA-based branching goes stale within months.

Conditional CSS. Modern CSS @supports queries beat UA-based CSS. @supports (display: grid) is more accurate than "if Chrome ≥ 57."

Bot blocking. UA is trivially spoofable. Use rate limiting, honeypots, and behavioral signals instead.

Privacy: UA is high-entropy fingerprinting

A UA string plus a screen size plus a timezone plus a set of installed fonts identifies most users uniquely across sites. That's why:

• Safari reduced its UA — most Macs report the same UA regardless of version.
• Firefox's Enhanced Tracking Protection freezes UA in private windows.
• Chromium's User-Agent Reduction removed minor version and platform info from the default UA, moving them to opt-in Client Hints.

The direction: less info by default, structured hints on request. If you're building a service that logs UAs, treat them as PII and apply the same retention policies you'd apply to IP addresses.

Debugging server logs and analytics

When investigating "why is X% of my traffic showing as Unknown Browser?":

1. Grep for the UA strings marked Unknown. Usually you'll find one common pattern.
2. Paste it into User-Agent Parser to see what it actually is.
3. Check for new browsers — Brave (Chromium-based), Vivaldi, Arc, DuckDuckGo mobile. They ship distinct UA tokens but most parsers miss them.
4. Look for bots that stopped spoofing — SEO tools, uptime monitors, some AI crawlers now proudly identify themselves.

Related: for AI crawlers specifically, check GPTBot, ClaudeBot, PerplexityBot, and CCBot in your logs. They're distinct from browser UAs and worth tracking as their own segment.

Testing UA-conditional code

When your code branches on browser detection, test with:

• curl -A — send a custom UA. Convert curl commands with cURL Converter to get equivalent fetch/axios code.
• Chrome DevTools → Device Emulation — spoofs UA + viewport + Client Hints.
• Bug reports with the real UA — paste into User-Agent Parser to reproduce the browser environment.

Never rely on if (userAgent.includes("Chrome")) — Edge, Opera, Brave, and every other Chromium browser include "Chrome" in their UA.

Related workflows

• HTTP Status Codes — for the 403 you return to blocked UAs.
• cURL Converter — for testing UA-conditional endpoints.
• JSON Formatter — for reading structured Client Hints logs.