Free User Agent Parser Online

User Agent Parser: Break a UA String Down into Browser, OS, and Device

Every request a browser makes carries a User-Agent string along with it — a single dense line of text like Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/120.0.0.0 Safari/537.36 that's meant to identify the browser, its version, the rendering engine underneath it, and the operating system it's running on. A user agent parser takes that string and splits it back into readable fields instead of leaving you to decode the abbreviations by eye, reporting the browser name and version, the rendering engine, the operating system and its version, the device type, and the CPU architecture as separate, labeled values.

This tool opens with your own browser's actual User-Agent string already loaded into the input box, read straight from the page you're viewing right now, so you can see your own setup parsed immediately without typing anything. The text box stays fully editable, though — replace it with any User-Agent string you've copied from a server log, a support ticket, or another device entirely, and the parsed fields update to describe that string instead of your own browser.

How to Parse a User Agent String

1. On load, the input box already contains your current browser's own User-Agent string, and the result cards below it are already populated with your browser, OS, engine, device, and CPU details.
2. To inspect a different string — one pulled from a server access log, an email header, or a bug report someone sent you — select the text in the box and replace it, or paste over it directly.
3. As soon as the text changes, six result cards refresh: Browser, Operating System, Device, Rendering Engine, CPU Architecture, and a Bot Signature indicator.
4. The Device card reports "Desktop" when no mobile or tablet signature is detected in the string, or the specific device type — mobile, tablet, and so on — along with vendor and model information when the string includes it.
5. The Bot Signature card flags whether the string matches a list of known crawler and bot identifiers — search engine crawlers, social media link-preview bots, and a few AI-crawler user agents among them — useful for a quick gut check on whether a log line came from a real visitor or an automated crawler.
6. Click the copy button above the input box at any point to copy the exact string currently loaded, whether that's your own browser's original value or one you pasted in to inspect.

All of this parsing happens as JavaScript running in the page itself — there's no upload step, and pasting in a string you copied from somewhere sensitive, like an internal log file, never sends that text anywhere beyond your own tab.

Why People Need to Decode a User Agent String

• Debugging a layout that only breaks on one device. A support message that includes a raw User-Agent string is far more useful once it's translated into "iOS 17, Safari, mobile" than left as an unreadable block of version numbers and platform tokens.
• Reading web server or analytics logs. Access logs record the User-Agent header for every request, and pulling a specific line out to understand exactly what browser and OS combination triggered an error is a routine part of investigating a server-side bug report.
• Checking how a site is likely to treat a specific browser. Before writing browser-specific CSS or JavaScript workarounds, confirming exactly which engine and version a target browser reports helps avoid guessing at compatibility.
• Distinguishing real visitors from crawlers in traffic data. Search engine bots, social sharing previews, and increasingly AI-related crawlers all identify themselves in their own User-Agent strings, and separating that automated traffic out is a common first step in cleaning up analytics numbers.
• Verifying a device-detection or analytics library. If your own site's device-detection code reports something unexpected for a particular visitor, running the same raw string through an independent parser is a fast way to check whether the string itself is unusual or your detection logic has a bug.
• Documenting a supported-browser matrix. Writing down exactly which browser engines and OS versions a project officially supports is easier once you can paste in a handful of representative strings pulled from real traffic and confirm each one parses to the version range the documentation claims to cover.

What Each Parsed Field Represents

Field	What it identifies	Example
Browser	The browser application and its self-reported version number	Chrome 120.0.0.0
Rendering engine	The underlying engine that actually renders the page — often shared across multiple browser brands	Blink 120.0.0.0
Operating system	The platform the browser is running on, with version where the string includes one	Windows 10
Device	Whether the request came from a phone, tablet, or a device with no mobile signature (reported as desktop)	Desktop
CPU architecture	The processor architecture token embedded in the string, when present	amd64
Bot signature	Whether the string matches a known crawler or automated-bot identifier — a separate keyword check layered on top of the parsed fields above	Not detected

The browser, engine, OS, device, and CPU fields all come from the same underlying parsing library — ua-parser-js, a maintained, open-source database of User-Agent signatures matched against the string you provide, rather than a short list of hand-written regular expressions that only recognize a handful of common patterns. The bot-signature check works differently: it's a simple keyword match against known crawler and bot identifiers layered on top of the library's output, catching common cases like search engine crawlers and social-media preview bots without claiming to be an exhaustive or foolproof bot-detection system.

Why a User Agent Is an Estimate, Not a Guarantee

A parsed User-Agent string describes what the browser claims to be, not what it's cryptographically proven to be, and two separate limitations are worth keeping in mind before treating the result as gospel. First, a User-Agent string is trivial to override — browser extensions, developer tools, automated testing frameworks, and command-line HTTP clients can all set an arbitrary string, so a request claiming to be an iPhone running Safari might really be a script running on a server somewhere. Second, and increasingly common even without any deliberate spoofing, several modern browsers now deliberately freeze or reduce the detail their User-Agent string exposes as a privacy measure — Chrome's User-Agent Reduction effort, for instance, caps the reported OS version and reduces some platform detail, encouraging sites to use the separate User-Agent Client Hints mechanism for anything more specific instead of parsing the string itself. The practical result is that a parsed OS version, in particular, may show a generic or frozen value rather than the browser's true, exact platform version. Treat this tool's output as a solid, generally reliable read on what a request is presenting itself as — useful for the overwhelming majority of real traffic — rather than a tamper-proof identification of the device that sent it. Device-type classification carries its own version of the same fuzziness: a phone or tablet browsing in a "request desktop site" mode can drop its usual mobile signature from the string entirely, and manufacturer- and platform-specific tokens aren't always applied consistently across every model, so an occasional tablet-versus-phone misread is expected rather than a sign of a broken parser.

Manually Reading a UA String vs. Using a Parser

• Reading it by eye. A short, common User-Agent string from a mainstream desktop browser is often readable without tooling once you know the pattern, but strings from less common browsers, embedded webviews, or older mobile devices pack in enough historical compatibility tokens that eyeballing them reliably takes real familiarity with the format's history.
• Browser developer tools. Chrome, Firefox, and Safari's device-emulation panels let you override your own browser's outgoing User-Agent string for testing, which is useful for simulating a specific device but doesn't help you decode a string someone else sent you.
• Server-side detection libraries. Many backend frameworks bundle their own User-Agent parsing for analytics or content adaptation, which is convenient when it's already part of your stack but adds a dependency if all you need is a one-off lookup.
• This parser's API. A log-processing job, an analytics pipeline, or any other automated workflow that needs User-Agent parsing outside a browser tab can call the identical ua-parser-js-backed routine through this site's metered API: post a User-Agent string and get the browser, engine, OS, device, and CPU fields back as structured JSON instead of a rendered card layout. Full request and response details, including the current credit cost, are documented on the API reference page.

Can a User-Agent string be faked?

Yes, easily. Browser developer tools, extensions, and automated scripts can all set an arbitrary User-Agent value, so a parsed result describes what a request claims to be rather than a verified fact about the device that sent it. Treat it as a strong signal for ordinary traffic, not as proof against a determined attempt to disguise the source.

Why does my browser's version look less specific than I expected?

Several modern browsers now intentionally reduce or freeze parts of their User-Agent string for privacy reasons rather than reporting the exact build number, favoring a separate opt-in mechanism (Client Hints) for sites that need finer detail. A generic or capped OS or browser version in the parsed result often reflects that deliberate reduction rather than a parsing error.

Does pasting a User-Agent string into this tool send it anywhere?

No. Parsing happens entirely as JavaScript in your browser tab using the ua-parser-js library — nothing you type or paste into the box is uploaded or transmitted, whether it's your own browser's string or one copied from a log file elsewhere.

Is the bot-signature check the same thing as the browser/OS parsing?

No — the browser, engine, OS, device, and CPU fields come from the ua-parser-js signature database, while the bot-signature indicator is a separate, simpler keyword match against known crawler and bot identifiers layered on top. It catches common, well-known bots but isn't presented as an exhaustive or unbeatable detection method.

Why did this tool classify a phone as a desktop device?

A phone browser set to request the desktop version of a site often strips its usual mobile signature out of the User-Agent string, and some less common device models simply don't include a token this parser's signature database recognizes as a mobile marker. When no mobile or tablet signature is present in the string, the Device card reports desktop by default rather than guessing.

Related Network Tools

Pair a parsed User-Agent string with a couple of related lookups for a fuller picture of a request. The what is my IP tool reports the public address and browser/OS details your own current request reveals, using the same underlying parsing this tool exposes directly. If the device in question is on a network you're mapping out, the IP subnet calculator works out the address range it belongs to.