User-Agent Parser: Read Browser Strings Without Guessing

Every browser sends a user-agent string with its requests: a line of text announcing, in a convoluted historical dialect, which browser, version, operating system and device it claims to be. Servers, analytics tools and developers read these strings to understand their visitors, tailor content, and diagnose problems. The strings are famously messy, because they accumulated decades of compatibility claims: a modern browser's string may name several other browsers and platforms it is not, purely so that old websites treat it correctly. Parsing them by eye is error-prone, which is why a parser exists.

The User-Agent Parser takes a pasted user-agent string and breaks it into its parts: browser name and version, operating system and version, device type, and engine details where they can be determined. It works from text you paste in; it does not track visitors or require credentials, and you should never paste secrets, tokens or private data into it. A user-agent string is identification text sent by a browser, not a credential, and that is all the tool needs. If a string you are examining contains anything beyond browser identification, redact it before pasting.

A typical desktop user-agent string contains several recognisable pieces: a Mozilla compatibility token at the start, which is historical and does not mean the browser is Mozilla Firefox; a platform token naming the operating system; an engine token; and a browser token naming the actual browser and version. Mobile strings add device and mobile markers. Reading the string means finding the browser token, which usually appears near the end, and the platform token, which names the operating system, while ignoring the compatibility tokens that exist only for historical reasons. A parser does this reliably; a human scanning the string often picks the first familiar name, which is usually the wrong one.

What the parts mean

The browser token is the most useful part: it names the browser and its version, such as a current Chrome, Firefox, Safari or Edge release. Version matters for support decisions: a feature that works in recent versions may fail in older ones, and a bug that appears only in one version points at that version's engine. The operating system token names the platform, such as Windows, macOS, Android or iOS, sometimes with a version. The device token, where present, distinguishes phones, tablets and desktops, and sometimes names a specific model. The engine token names the rendering engine, which determines how pages are actually displayed and which quirks apply.

Bots and crawlers announce themselves differently, and parsing helps there too. Search engine crawlers, monitoring tools and social media preview fetchers send strings naming themselves, often with a link to information about the bot. Recognising these strings matters for analytics — bot traffic should not be counted as human visitors — and for troubleshooting, because a page that behaves oddly for a preview fetcher may be failing for social sharing rather than for humans. Treat bot strings with the same caution as browser strings, however: anyone can send any string, so a claim to be a search crawler is not proof of identity. Real search crawlers can be verified by other means, such as reverse DNS checks, when identity actually matters.

Version numbers deserve a caution. Browsers now update frequently and sometimes freeze or reduce version detail for privacy, so the version in a string may be less precise than it once was. Some browsers also send reduced strings by default, revealing less about the device. A parser reports what the string says, not what the device truly is, and the gap between those two grows as privacy protections increase. Use parsed results as a best reading of a claim, not as a verified fact about a device.

Worked example: diagnosing a layout complaint

Suppose a website owner receives a complaint that a page's layout breaks, but only for one visitor. The visitor supplies their user-agent string, and the owner pastes it into the parser. The result shows an older browser version on an older mobile operating system, with a small-screen device marker. The owner's own testing used current browsers, so the bug never appeared there. The parsed result suggests the cause: a layout feature unsupported by the older browser version, combined with a narrow screen that exposes the fallback's flaw.

The owner tests the page in an emulator or device matching the parsed profile and reproduces the breakage: a grid layout falls back poorly on the older engine. The fix is a simpler fallback for that layout, tested against the older profile, and the page then works for both the complaining visitor and everyone else. Without parsing, the owner might have guessed at the visitor's browser from the complaint's wording, or asked the visitor to try a different browser, which treats the symptom rather than the cause. Parsing turned a vague complaint into a specific, reproducible test case.

The example also shows the right boundary: the parsed string guided diagnosis, but the fix was verified by testing, not by trusting the string alone. If the visitor's string had been spoofed or reduced, the parsed result might have pointed at the wrong profile, and testing would have revealed the mismatch. Parsing is a compass, not a map: it points the investigation in the right direction, and testing confirms the destination.

What user-agent detection should not do

User-agent strings should not be used for security decisions. Because anyone can send any string, a check that grants access or skips verification based on a user-agent claim is trivially bypassed. Authentication, authorisation and input validation must rest on credentials and server-side checks, never on a self-declared browser name. Similarly, user-agent detection should not be the sole basis for serving different content, because it is fragile: strings change, new browsers appear, and reduced strings reveal less over time. Prefer feature detection — testing whether the browser supports the feature you need — for content decisions, and reserve user-agent parsing for analytics, diagnostics and support, where an approximate answer is useful and a wrong answer is harmless.

Privacy is a further consideration. User-agent strings contribute to browser fingerprinting, which is why browsers are reducing their detail. Collect and store parsed results only where you have a reason, such as analytics or support, and avoid combining them with other identifying data unnecessarily. When sharing a user-agent string for debugging, such as in a support ticket, remember that it reveals the reporter's browser, operating system and sometimes device model; that is usually acceptable in a support context, but it should not be published publicly without thought.

For related parsing and inspection work, the URL Parser breaks addresses into their components in the same spirit, and the SEO Checker shows how a page presents itself to crawlers and visitors. For caching behaviour that varies by browser, see Browser Cache Policy Builder Guide.

FAQs

Why does a Chrome string mention Mozilla and Safari? For historical compatibility. Early browsers added tokens to be treated correctly by sites that checked for specific names, and later browsers kept those tokens so old checks would not break. The tokens are legacy claims, not descriptions of the actual browser.

Can a user-agent string prove which browser someone used? No. It reports what the client claimed, and clients can claim anything. It is reliable enough for analytics trends and diagnostics, but never for identity or security.

Why do some strings show less detail than others? Browsers increasingly reduce user-agent detail for privacy, and some send a reduced string by default. Parsers report the detail present; where detail is reduced, the honest result is a broader category rather than a precise version.