Pulling browser, OS, and device class out of one long string
The string 'Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/128.0.0.0 Safari/537.36' parses into browser Chrome 128.0.0.0, OS Windows, and device class desktop.
Notice the string contains both 'Chrome/128.0.0.0' and 'Safari/537.36' -- this is normal, not a conflict: Chrome's user agent deliberately includes a Safari token for legacy compatibility with sites that only check for 'Safari' to detect WebKit-based browsers, a historical artifact of browser identification wars from years ago.
'Windows NT 10.0' in the string maps to the marketing name 'Windows' (specifically Windows 10 or 11, which share the same NT 10.0 kernel version number) -- the raw NT version number alone can't distinguish between Windows 10 and Windows 11 without additional signals.
Why this parsing is a best-effort guess, not a guarantee
Regex hints only. Client hints and reduced UA strings can hide the real build. User-Agent parsing has always relied on pattern-matching known string formats -- there's no strict standard forcing browsers to structure their UA string in a fully parseable way, and browser vendors have historically added, removed, or frozen tokens for privacy and compatibility reasons.
Modern browsers increasingly send a 'reduced' or frozen User-Agent string (especially Chrome, moving toward User-Agent Client Hints) that intentionally provides less granular version and platform detail than older UA strings did, specifically to reduce fingerprinting -- a reduced UA can make this kind of regex-based parsing less precise over time.
This is entirely client-side, self-reported text -- any client can send a User-Agent string with any content it chooses, so parsing it correctly reflects what was sent, not necessarily an unforgeable fact about the actual browser or device making the request.
Related header and request-debugging tools
The User-Agent is just one header among several in a request -- see the HTTP Header Parser to parse a full raw header block.
If device class detection is feeding into a responsive design or analytics decision, cross-check against actual viewport and screen-size data rather than relying on User-Agent alone, since UA-based device detection is a heuristic, not a certainty.
Frequently Asked Questions (FAQ)
Why does a Chrome user agent also contain 'Safari' in the string?
It's a long-standing legacy compatibility convention -- Chrome (and other WebKit/Blink-based browsers) include a Safari version token so that older websites checking specifically for 'Safari' to detect WebKit rendering behavior still work correctly, even though the browser is actually Chrome.
How does 'Windows NT 10.0' become the OS label 'Windows'?
The NT 10.0 kernel version number corresponds to both Windows 10 and Windows 11, which share that same underlying version string in the User-Agent -- the parser maps that pattern to the general 'Windows' label rather than guessing which specific edition.
Is User-Agent parsing always accurate?
Regex hints only. Client hints and reduced UA strings can hide the real build. No -- it's pattern-matching against known string formats, not a guaranteed protocol. Browsers can freeze, reduce, or omit detail in their UA strings, and any client can technically send an arbitrary User-Agent value.
Why are browsers sending 'reduced' User-Agent strings now?
Major browsers, particularly Chrome, have been moving toward frozen or reduced User-Agent strings and User-Agent Client Hints specifically to limit browser fingerprinting for privacy reasons -- this intentionally provides less granular detail than older, fully detailed UA strings did.
Can I trust the User-Agent to reliably identify device type for critical logic?
Not as the sole signal. Since User-Agent is self-reported and can be spoofed or altered, use it as one heuristic input, and pair it with actual capability detection (viewport size, feature detection) for anything where accuracy genuinely matters.
