Why user-agent strings look insane
Every modern browser claims to be Mozilla/5.0, most claim AppleWebKit, and Chrome-family browsers also claim Safari, thirty years of browsers impersonating each other so that badly written server-side detection wouldn't lock them out. The practical consequence: you must check for the most specific token first. Edge contains "Chrome", so test for Edg/ before Chrome/; Chrome contains "Safari", so Safari is only Safari when Chrome is absent. This parser applies those precedence rules for you.
What log analysis actually uses this for
Grepping access logs, the questions are usually: is this traffic spike humans or a crawler? Which monitoring probe is hammering that endpoint? Is anyone still on the browser version we're about to drop? The parser recognises the bots and tools you meet most in server logs: Googlebot, Bingbot, curl, wget, python-requests, Go's http client, uptime monitors, and AI crawlers like GPTBot and ClaudeBot, because in a typical public server's logs, automated clients often outnumber humans.
The honesty problem
A user-agent is a self-declaration, not an identity. Scrapers routinely present Chrome's exact UA; conversely, real users behind corporate proxies sometimes arrive with rewritten strings. For anything security-relevant, verify claims independently, genuine Googlebot requests, for example, come from IPs that reverse-resolve to googlebot.com. Treat UA parsing as strong evidence for analytics and weak evidence for access control.
The future is structured
Chromium has been freezing and reducing UA detail for years in favour of Client Hints (Sec-CH-UA-* headers), which deliver the same facts in parseable form, on request. New tooling should prefer Client Hints where present and fall back to UA parsing, which, given the decades of legacy clients out there, will still be with us for a long time.