User Agent Parser
Break a user agent string into browser, engine, operating system and device.
User Agent Parser tool
| Browser | |
|---|---|
| Rendering engine | |
| Operating system | |
| Device type | |
| Device model | |
| Automated client |
What this tool does
Paste a User-Agent header — or press the button to fill in your own — and this
page splits it into browser, rendering engine, operating system, device type and, where the
string admits it, the crawler behind it. Parsing happens in this tab.
Underneath the table is a list of the specific ways the string you pasted is misleading — the reason this tool exists, since almost every field in a modern UA string is either inherited from a browser that no longer exists or deliberately frozen.
Common uses
- Answering “what is my user agent” before pasting it into a bug report.
- Reading an access log entry and working out whether a spike was real traffic or a crawler.
- Checking what an in-app WebView reports, which is rarely what the app's users think they are running.
- Confirming that a device-detection rule does what you think — particularly the iPad case below, which breaks most rules written before 2019.
A short example
Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36
(KHTML, like Gecko) Chrome/128.0.0.0 Safari/537.36
Four of the six product tokens here are fiction: not Mozilla, not KHTML, not “like Gecko”,
certainly not Safari. The only load-bearing token is Chrome/128.0.0.0, and even
that has had its last three numbers zeroed. Windows NT 10.0 covers both Windows 10 and 11.
Why every browser claims to be every other browser
In 1993 Mosaic could not render frames and Netscape could. Servers began checking for the
token Mozilla before sending the good version of a page, so Internet Explorer
started sending Mozilla/4.0 (compatible; MSIE …) to get it too. Every browser
since has inherited the pile: Safari added AppleWebKit and like Gecko; Chrome added Safari/537.36 so WebKit sniffing would keep working; Edge added
Edg/ after Chrome/ so that badly written checks would still see
Chrome. This is why a parser must test Edge before Chrome and Chrome before Safari — the
reverse order reports every browser on earth as Safari.
The sharpest edge today is the iPad. Since iPadOS 13, Safari on an iPad sends a string
identical to a Mac's, down to Macintosh; Intel Mac OS X 10_15_7. The only
surviving difference is a Mobile/15E148 token that desktop Safari never sends,
which is what this parser keys off.
Worth knowing
User-Agent Client Hints are the replacement. Chromium browsers now send
Sec-CH-UA, Sec-CH-UA-Mobile and Sec-CH-UA-Platform on
every request, with high-entropy values such as the full platform version available only via
Accept-CH. Firefox and Safari do not implement them. Either way the durable
advice is unchanged: detect features with @supports and capability checks, use
responsive layout for size, and reserve UA parsing for analytics and bug reports, where being
wrong about a few per cent of traffic is survivable. Anyone can send any string, so a UA is a
claim, never a fact.
Frequently asked questions
Why does Chrome on an iPhone say it is Safari?
Because underneath it is: browsers on iOS render through the system WebKit, so the string is Safari’s with one token added. Chrome writes CriOS/ where Safari puts Version/, Firefox uses FxiOS/ and Edge uses EdgiOS/. Test for those before you test for Safari, or your analytics will hand Safari every iOS visit on the site.
How do I tell an in-app browser from the real one?
By what is added, or missing. An Android WebView adds ; wv to the platform section, and the Facebook and Instagram apps append tokens such as FBAN/, FBAV/ or Instagram. On iOS the signal is an absence: a WKWebView sends Mobile/15E148 but no Version/ and no Safari/ token at all. Worth detecting, because in-app browsers routinely break OAuth pop-ups and file downloads.
Can I trust a user agent that claims to be Googlebot?
No — the string is free to type, and scrapers use it constantly to slip past rules that whitelist it. Google’s documented check is a reverse DNS lookup on the requesting IP, which must resolve to a host under googlebot.com or google.com, followed by a forward lookup back to the same address; Google also publishes its crawler ranges as JSON. Verify before serving anything a normal visitor would not see.