User Agent Parser
Break down any user-agent string into browser, engine, operating system, device type and bot status. The detection rules ship with the page, so a string pasted from a server log is never sent anywhere, which is the point, given what else lives in those logs.
User agent parserPaste a user-agent string, or read this browser's own
Chrome on iOS reports as Safari, and Edge contains both a Chrome token and a Safari token. Token order decides the answer, and a parser that checks in the wrong order calls Edge “Chrome” and calls Chrome-on-iPhone Blink, which Apple does not allow to exist. Both cases are in the examples above, so you can watch this one get them right.
Common questions
- Why does Chrome on iPhone report itself as Safari?
- Because on iOS every browser is required to use Apple's WebKit engine, so Chrome's string contains Safari and WebKit tokens and adds CriOS to identify itself. A parser that checks for Safari first will call it Safari. The order tokens are checked in decides the answer, and getting it wrong here is one of the most common misparses in the wild.
- Why is Edge sometimes reported as Chrome?
- Same reason, one step further. Edge is built on Chromium, so its string contains Chrome, Safari and AppleWebKit tokens, with Edg at the end. Check for Chrome before Edg and every Edge visitor is counted as Chrome. This is tested explicitly here.
- Why does my Mac report macOS 10.15 when I am on a much newer version?
- Because Apple froze the reported version at 10_15_7 for privacy, so the string stops distinguishing between releases after Catalina. Windows does something similar, and Chrome now freezes much of its own version detail. No parser can recover what the browser has chosen not to send, and the tool says so rather than guessing.
- Can I trust a user-agent string?
- No, and nothing that depends on trusting one is safe. It is a self-reported header that any client can set to anything, and one line of code changes it. It is fine for analytics, compatibility notes and debugging. It is not authentication, not proof of device, and not a security control.
- How is bot detection done?
- By matching against a bundled list of around a hundred known crawler signatures: Googlebot, Bingbot, and the common monitoring and scraping agents. A match is reliable. A non-match only means the string is not on the list, since a bot that wants to look like a browser simply says it is one. The tool reports it that way rather than as a verdict.
- Why parse user agents locally at all?
- Because the strings usually arrive with company. They are pulled from server logs and analytics exports, sitting alongside IP addresses, session identifiers and request paths. Pasting that into someone else's web service means handing over the surrounding context too. This page carries its own rules and makes no requests.
Exact about what the string says: token extraction and the browser, engine, OS and device rules are deterministic and verified against real strings. It is never evidence about what actually sent the request. User-agent strings are self-reported and trivially spoofed, the bot signatures are a bundled list so a miss is a miss rather than proof of a human, and modern browsers deliberately withhold the true OS version and device model.