gizmobench
BrowseDaily

User Agent Parser

Paste a user-agent string, an HTTP User-Agent header or a whole log line. The parser extracts one user-agent value and reports browser, engine, operating system, device type and matching bot signatures using bundled rules. Use mine fills this browser's own value, and fields can be copied. The string is self-reported, so the result describes its claims rather than proving the sender's identity.

User agent parserNothing pasted yetPaste a user-agent string, or read this browser's own
User agent
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?
Chrome on iPhone user-agent strings can include Safari and WebKit tokens and add CriOS to identify Chrome. This parser checks that distinguishing token before Safari. A shared token alone is not enough to identify the browser, and the parsed result remains a claim made by the string.
Why is Edge sometimes reported as Chrome?
Edge strings include Chrome, Safari and AppleWebKit tokens, with an Edg token identifying Edge. Checking Chrome first can mistake that shared token for the browser name. This parser gives the more specific Edge token priority.
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?
The parser matches a bundled list of crawler, monitoring and HTTP-client signatures. A match identifies a signature in the supplied text, rather than proving the request came from that named crawler. A non-match does not prove a human sent it, because a client can imitate a browser string.
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.
Can I parse a bulk list or a server log file?
The field reads one user-agent value or one log line at a time. It can extract the appropriate quoted field from a supported combined log line while ignoring the request, referrer and address fields. There is no batch table, log-file uploader or bulk CSV export.
Is this a JavaScript, Node, npm or other language library?
The parsing runs in this browser page. The page does not provide an installable package, public parsing API or code integration for JavaScript, Node, Java, PHP, Python, C#, Go, Ruby, SQL or application frameworks. You can inspect a supplied string here and copy its reported fields.

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.