User Agent Parser – Browser, OS & Device Detector

What a User-Agent String Contains and How This Parser Reads It

Every browser announces itself on each request with a user-agent string, a single line of text that names the browser, its version, the operating system, and the rendering engine. Buried in that line is exactly what you need when a bug report says only that the site looked broken. This parser splits any string into readable fields: browser and version, OS and version where present, device class of mobile, tablet, or desktop, and engine. Your own string loads and parses the moment the page opens, and you can replace it with one copied from a server log, an analytics export, or a support ticket. Developers triaging bugs, QA engineers recording test environments, and analysts sanity-checking device splits are the regular users. Reading these strings by hand goes wrong because of decades of deliberate misdirection. Almost every modern browser opens with Mozilla slash 5.0 and most include the token Safari, whether or not they have anything to do with either. That happened because early servers gated the good version of a page behind a Mozilla check, so everyone claimed to be Mozilla, and the habit calcified into the standard. The parser deals with it by ordering its checks from most specific to least: it looks for Edg before Chrome, because Edge carries both, and Chrome before Safari, for the same reason. OS detection reads the platform token inside the first parenthesised group, so Windows NT 10.0 becomes Windows 10, and iPhone OS 17_4 becomes iOS 17.4 with the underscores converted. Device class is inferred from tokens like Mobile, Tablet, and iPad rather than from screen size, which the string never carries. Here is a real string, broken apart. Take Mozilla slash 5.0 open-paren iPhone; CPU iPhone OS 17_4 like Mac OS X close-paren AppleWebKit slash 605.1.15 open-paren KHTML, like Gecko close-paren Version slash 17.4 Mobile slash 15E148 Safari slash 604.1. The parser reports Browser: Safari 17.4, taken from the Version token rather than the trailing Safari 604.1, which is a frozen build number and not a real version. OS: iOS 17.4, from iPhone OS 17_4 with the underscore normalised. Device: mobile, because of the Mobile token. Engine: WebKit, from AppleWebKit. Note that the string also claims KHTML and Gecko, both untrue, and mentions Mac OS X — read literally you would conclude this is a desktop Mac running Gecko, which is precisely the trap the ordered checks avoid. Where it earns its place. A support engineer receives a ticket saying the checkout button does nothing, pastes the UA from the session log, and finds Samsung Internet 21 on Android 11 — a browser nobody on the team had tested. A QA lead writing a release note pastes each device UA to record exact versions instead of writing tested on iPhone. An analyst notices tablet traffic collapsed overnight, checks a sample string, and discovers iPadOS now reports a desktop Safari UA by default, so the old classification rule silently broke. A developer debugging a CSS bug that only reproduces on one laptop confirms the colleague is two Chrome major versions behind. A couple of honest limits. The string is self-reported and trivially spoofed — curl, Postman, and any browser extension can send whatever they like — so never treat it as a security signal or a way to gate access. The bigger pitfall is using it for code branching at all: browsers are actively freezing and reducing UA detail, Chrome has been trimming its string for years, and version numbers you rely on today may simply stop being reported. Use feature detection for behaviour and keep the user-agent for diagnostics, analytics, and documentation, which is what it is genuinely good for. Parsing runs entirely in your browser inside a client-side effect, so your own string and anything you paste from production logs stay on your device and are never uploaded.

🔥 Trending Tools