Why User-Agent strings are such a mess to parse

Modern User-Agent strings carry decades of accumulated compatibility baggage — Chrome's UA string still contains the word "Safari" and reports itself as "Mozilla/5.0," a legacy from an era when servers made decisions based on which browser names appeared in the string, and every new browser wanted to pass those same checks. That history means a User-Agent string genuinely has to be parsed in a specific priority order — checking for more specific tokens like "Edg/" before falling through to more generic ones like "Chrome/" — because a browser's string can legitimately contain multiple engine/browser names simultaneously, and only the more specific match is the actually correct one.

Why this is a best-effort guess, not ground truth

Nothing prevents a browser, extension, or a deliberately crafted HTTP client from sending any User-Agent string it wants — browsers themselves ship built-in UA override features for testing, and plenty of tools spoof a common browser string to avoid being blocked. That means parsing a User-Agent string tells you what the client claimed to be, not what it verifiably is; for access-log analysis this is normally accurate enough to be genuinely useful (most real traffic doesn't bother spoofing), but it should never be treated as an authoritative identity check the way, say, a TLS certificate would be.