User-Agent parser

What is a User-Agent string?

The HTTP User-Agent header is a text field every client — browser, mobile app, scraper, CLI tool — sends to identify itself. The format accreted historically rather than being designed: every entry was added because some server-side check rejected clients without it. That is why every modern browser still claims to be every other browser in some way.

A typical UA carries the platform, layout engine, browser version, and a chain of compatibility tokens. Servers parse it for analytics, A/B targeting, bot detection, and legacy feature toggles — none of which is fully reliable, because the field is freely chosen by the client.

How it works

A typical desktop UA reads Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/120.0.0.0 Safari/537.36. The Mozilla/5.0 prefix is universal and meaningless. The platform comment names the OS. AppleWebKit/... identifies the layout engine. Chrome/... and trailing Safari/... tokens exist so servers checking for either keep working.

Chrome, Edge, and Safari have begun freezing the version portion of the UA and steering developers toward User-Agent Client Hints (UA-CH) — separate headers like Sec-CH-UA and Sec-CH-UA-Platform.

When to use this tool

• Decoding a UA from a server log to identify the client OS and browser.
• Sanity-checking the UA your application sets on outbound requests (custom CLI tools, cron jobs, SDKs).
• Investigating bot traffic that may be forging a browser identity.
• Building or verifying a UA-based analytics pipeline.
• Reviewing what data your browser exposes when you send a request.

Common pitfalls

• The UA is trivially spoofable. curl, wget, and every HTTP library lets the caller set any string. Treating the UA as authentication or proof of platform is a mistake.
• Version-based feature detection is unreliable. The version reported may be frozen, lied about, or behind a flag. Feature-detect at runtime with typeof navigator.someAPI, not by parsing a string.
• UA parsing libraries lag the real world. New browsers, new mobile devices, and new bot frameworks appear constantly; a static parser will misclassify them.
• Mobile detection by UA is fraught. Foldables, tablets, and desktop mode toggle the platform string. CSS media queries and Client Hints are more reliable for layout decisions.
• UA-CH is opt-in per origin and gated on HTTPS. Code that reads Client Hints needs to send the right Accept-CH header on a previous response or the values will be missing.

Frequently asked

Why does Chrome's User-Agent say Safari?

Because Chrome shipped on top of WebKit (and still claims compatibility with it via the trailing Safari/... token) and any server that checked for Safari needed to keep working when Chrome arrived. The token persisted long after the engines diverged.

Should I use User-Agent for feature detection?

No. Feature-detect at runtime — check whether the API or property exists. UA-based feature detection breaks every time a browser tweaks its string, and it lies about clients that intentionally spoof.

What is User-Agent Client Hints?

UA-CH is a set of headers (Sec-CH-UA, Sec-CH-UA-Platform, Sec-CH-UA-Mobile) that replace the freeform UA string with structured fields the server explicitly asks for. It is the long-term replacement for parsing UAs.

How do I detect mobile reliably?

Use CSS media queries (@media (pointer: coarse)) for layout, and Sec-CH-UA-Mobile for server-side decisions. UA parsing is the least reliable option.