Web & Network
User-Agent Parser — Browser, OS & Device
Parse a User-Agent string into browser, OS, rendering engine and device type.
Runs entirely in your browser — nothing you paste is uploaded or stored.
What is user-agent parser?
A User-Agent string is a line of text every browser sends with each request, identifying itself, its version, the operating system it's running on, and its rendering engine. The format is famously messy — for historical compatibility reasons, nearly every modern browser's User-Agent claims to be several other browsers at once — which makes it easy to misread by eye. This tool parses a User-Agent string properly, checking the more specific signatures first, and shows exactly what it identifies: browser, OS, engine and device type, either for a string you paste in or for your own browser automatically.
When to use it
- Debugging a bug report that includes a raw User-Agent string, to see at a glance what browser, version and OS it actually describes.
- Checking what your own browser is currently sending, when investigating browser-detection logic or a User-Agent-based redirect.
- Understanding a log line or analytics entry that records the User-Agent of a visitor or request.
- Verifying that a crawler or bot identifying itself in a User-Agent string is who it claims to be.
How to use this tool
- Paste a User-Agent string into the box, or click "Use my browser's User-Agent" to inspect your own — it's filled in automatically when the page loads.
- Read the parsed result: browser name and version, operating system and version, rendering engine, device type, and, where present, device model, CPU architecture and in-app browser.
- Scroll to "What each part means" to see the raw string broken into its individual pieces, each one underlined with a plain-English explanation of why it's there.
- Copy the raw string with the copy button if you need to paste it elsewhere.
Example
A desktop Chrome User-Agent on Windows.
Input
Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/128.0.0.0 Safari/537.36Output
Browser Chrome 128.0.0.0
OS Windows 10/11
Engine Blink (Chromium)
Device Desktop
CPU arch. x64Note the string also contains "Safari/537.36" — that's the historical compatibility token every Chromium browser carries, not a sign this is actually Safari.
Reading the version numbers
Not every OS version is what it appears to be at a glance: recent Windows 10 and Windows 11
both report Windows NT 10.0 — Windows itself dropped the version number from the User-Agent
string years before Windows 11 shipped, so the two are indistinguishable from this string
alone. iOS and macOS versions appear with underscores instead of dots in the raw string
(17_5_1), which this tool converts to the familiar dotted form.
Frequently asked questions
Why does a Chrome User-Agent contain the word "Safari"?
For historical compatibility. When Chrome launched, many websites checked for the substring "Safari" to decide whether to serve modern CSS and JavaScript, since Safari was the reference WebKit browser at the time. Chrome (and every other WebKit- or Blink-based browser since, including Edge and Opera) kept that token in its User-Agent to avoid breaking those checks, which is exactly why parsing a User-Agent by eye is unreliable — you have to check the more specific tokens (Chrome, Edg, OPR) before falling back to Safari.
Can a User-Agent string be faked?
Yes, trivially — every major browser lets you override it in developer tools, and any HTTP client can set it to an arbitrary value. A User-Agent is a self-reported claim, not a verified fact, so it's useful for analytics and feature-detection heuristics but should never be trusted for a security decision.
Why is browser and OS detection considered unreliable practice for feature support?
Because the relationship between "browser X version Y" and "supports feature Z" changes constantly and requires a maintained lookup table that's always slightly out of date. Checking directly whether the feature exists — `if ('fetch' in window)`, for example — works regardless of which browser or version is asking, and keeps working as new browsers ship.
What does "engine" mean, and why does it matter?
The rendering engine is the underlying software that actually parses HTML/CSS and runs JavaScript — Blink (Chrome, Edge, Opera, and most Android browsers), WebKit (Safari, and every browser on iOS, since Apple requires it), and Gecko (Firefox). Two browsers sharing an engine tend to render pages near-identically, which is more relevant to compatibility testing than the browser's brand name alone.
Why do all browsers on iOS report the WebKit engine, even Chrome?
Apple's App Store policy requires every browser on iOS to use WebKit internally, regardless of its brand — so "Chrome for iOS" is Chrome's interface built on Safari's actual rendering engine, not Chrome's own Blink engine. This is unique to iOS; Chrome on Android and desktop uses Blink as normal.
What does the "What each part means" breakdown show?
It underlines every recognised chunk of the raw string — `Mozilla/5.0`, `AppleWebKit`, `KHTML, like Gecko`, the browser and version token, `Safari/537.36`, and platform details like `Win64; x64` — and, on hover or tap, explains in plain English why that particular chunk is there. It's aimed at the parts that confuse people at a glance, especially the historical-compatibility tokens that make nearly every browser's User-Agent claim to be several other browsers at once.
What is an "in-app browser", and why does it show up separately?
Apps like Instagram, Facebook and TikTok open links in their own embedded browser rather than the phone's default one, and append their own token (for example "Instagram 312.0.0.34.111") to the underlying WebView's User-Agent to identify themselves. This tool surfaces that token separately because it's often the actual cause of a rendering bug — in-app browsers frequently lack features the same OS's real browser supports.
Find these tools useful? A coffee helps keep them free and ad-light.
Buy me a coffee