BrowserTools
Advertisement
Home / Networking / User-Agent Parser

User-Agent Parser

Parse a User-Agent string into browser, engine, OS and device information.

Loading User-Agent Parser… If nothing happens, please enable JavaScript.

Frequently asked questions

What data does this tool send to your servers?
Nothing. User-Agent parsing runs entirely in your browser using a client-side JavaScript library. No UA string you paste or that is auto-detected is sent to our servers. There are no backend requests for this tool, so there is nothing to log or store.
Why do User-Agent strings contain 'Mozilla/5.0' even for Chrome and Safari?
This is a legacy compatibility artefact dating to the browser wars of the late 1990s. Web servers of the era served richer content to 'Mozilla' browsers and degraded content to others. To avoid being served degraded pages, each new browser added 'Mozilla/5.0' to its UA string regardless of its actual identity. The practice has continued for over 25 years and is now baked into the HTTP specification as expected behaviour.
Why doesn't the parsed result always match what I expect?
User-Agent parsing is inherently heuristic. New browser versions, unusual operating systems, and custom UA strings from apps or tools can confuse any parser. Some browsers deliberately misrepresent themselves (e.g. Opera used to report as Internet Explorer). Mobile apps that embed web views often report their own app name alongside the underlying WebView UA. If the parser shows 'unknown', the UA string is using an unconventional format the parser has not been trained to recognise.
What is the difference between the browser engine and the browser itself?
The rendering engine (e.g. Blink, Gecko, WebKit) is the underlying code that parses HTML, applies CSS, and executes JavaScript. The browser is the application built on top of that engine, adding the address bar, bookmarks, extensions, and interface. Chrome, Edge, Opera, Brave, and most Android browsers all use Blink. Firefox uses Gecko. Safari uses WebKit. Knowing the engine is often more useful than the browser name for debugging rendering compatibility issues.
Are there rate limits on this tool?
No. Because parsing runs entirely client-side in JavaScript, there are no server requests and therefore no rate limits. You can parse as many UA strings as you like with no throttling. The tool works offline once the page is loaded.
How does this compare to using navigator.userAgent in JavaScript?
'navigator.userAgent' in a browser's developer console gives you the raw UA string for that browser. This tool does the same thing but additionally parses the raw string into structured fields. It also lets you paste arbitrary UA strings from logs or other sources, which 'navigator.userAgent' cannot do since it only returns the current browser's UA.
What are Client Hints and how do they replace User-Agent?
Client Hints (specifically Sec-CH-UA, Sec-CH-UA-Platform, Sec-CH-UA-Mobile, and related headers) are structured HTTP request headers that provide browser identification in a machine-readable format rather than a freeform string. They were introduced by Google as part of the User-Agent Reduction initiative, which aims to cap the UA string to a fixed, low-entropy value to reduce passive fingerprinting. Servers that need detailed browser information must explicitly request it by returning an Accept-CH header.
Does this tool log User-Agent strings for analytics or advertising?
No. Since parsing is entirely client-side, no UA data is ever transmitted to our servers. There is nothing to log, share with advertisers, or store. Your browser performs all computation locally.
How do bots and crawlers identify themselves in the User-Agent?
Well-behaved bots like Googlebot (Google's web crawler), Bingbot (Microsoft), and common monitoring agents include identifying tokens in their UA strings following a rough convention of 'BotName/version (+url-with-info)'. Malicious scrapers often spoof legitimate browser UAs to avoid bot detection. Some detection signals beyond the UA include request rate, lack of JavaScript execution, and missing browser-specific headers like Sec-Fetch-Site.
Can I trust the OS and device information in a User-Agent?
For legitimate browsers on standard devices, the OS and device information is generally accurate because there is no incentive for end users to spoof it. However, any HTTP client can set any UA string — automation frameworks like Puppeteer and Selenium default to the real browser UA but can be configured to use any string. Privacy-focused browsers and extensions may randomise or spoof the UA on each request as a fingerprinting countermeasure, making the parsed information unreliable for security decisions.

About User-Agent Parser

The User-Agent header is a free-form text string that web browsers and HTTP clients send with every request, identifying the software making the connection. Despite being only one line of text, a well-formed User-Agent encodes a surprising amount of information: the browser family and version, the rendering engine it is built on, the operating system and its version, and often the device type or model. This information was originally intended to allow web servers to send browser-appropriate content in an era when Internet Explorer and Netscape rendered pages very differently. Today, User-Agent strings are used for analytics, bot detection, feature detection, and debugging web application compatibility issues.

Web developers paste User-Agent strings into parsers when a bug report comes in from a user on an unfamiliar platform and they need to understand exactly what browser and OS combination is involved. QA engineers use parsed UA data to verify their automated test suites are correctly identifying themselves. Security teams analyse User-Agents in server logs to identify web scrapers, vulnerability scanners, and bots. API developers check the UA of incoming requests to understand which client libraries and SDK versions their users are running. DevOps engineers correlate UA data with error rates to identify browser-specific compatibility regressions.

This tool parses User-Agent strings entirely in your browser using a client-side JavaScript library — no data is sent to our servers. Your browser's current User-Agent string is detected automatically on page load so you can see your own parsed result immediately. You can also paste any UA string you have copied from a server log or bug report to parse it on demand. The parser identifies the browser family, browser version, rendering engine (Blink, Gecko, WebKit, Trident), operating system, operating system version, and device category (desktop, mobile, tablet, bot). Results are displayed in a structured format with each field labelled clearly.

When reading parsed results, remember that User-Agent strings are not guaranteed to be accurate — any client can set any UA string it wants, and spoofing is trivially easy. Chrome on Android, for example, includes 'Mozilla/5.0' and 'Safari' tokens in its UA for historical compatibility reasons, which is why raw UA strings look bizarre even for well-known browsers. The 'frozen' Chrome UA project (started around 2021) aims to reduce information leakage by capping version numbers in the UA string and moving detailed browser identification to structured Client Hints headers (Sec-CH-UA-*). If you are building browser detection for production use, prefer the Client Hints API over User-Agent parsing where possible.

The String That Broke Itself: A Brief History of User-Agent Chaos

The User-Agent header was introduced in the first published HTTP specification in 1992, originally intended as a simple one-line identification of the software making a request — something like 'NCSA_Mosaic/2.0'. The chaos began almost immediately. When Netscape Navigator launched in 1994 and quickly dominated the browser market, web developers started serving 'enhanced' pages only to Netscape, which identified itself as 'Mozilla'. Microsoft's Internet Explorer, released in 1995, needed to receive the same enhanced pages, so it added 'Mozilla/2.0 (compatible; MSIE 3.0)' to its UA string — claiming to be Mozilla while also identifying itself as MSIE.

Every major browser that followed repeated the same pattern. Opera added Mozilla compatibility tokens. Safari, built on the KHTML engine forked into WebKit, added 'Mozilla/5.0 (... like Gecko)' to its string. Chrome, built on WebKit, added 'AppleWebKit' and 'Safari' tokens to ensure Safari-targeted code would also run in Chrome. The result is that a current Chrome UA string on Windows contains tokens for Mozilla, AppleWebKit, KHTML, Gecko, and Safari — five different references to competing browsers — none of which is Chrome's own identity, which appears only as 'Chrome/version' near the end.

Google announced the User-Agent Reduction project in 2020, with the goal of freezing the UA string to a low-entropy fixed value by 2022 and migrating detailed browser identification to the structured, opt-in Client Hints mechanism. The actual rollout was slower than planned due to web compatibility concerns — millions of web applications rely on UA string parsing for logic that cannot be easily migrated. This makes the User-Agent header a living example of how difficult it is to deprecate a flawed but deeply embedded internet standard: even after three decades and near-universal acknowledgment that the format is broken, the effort to replace it is measured in years.

Related tools

What's My IP, User Agent & Browser Info

See your public IP address, user agent, request headers and browser capabilities, instant lookup, no tracking.

WHOIS Lookup

Look up the WHOIS registration data for any public domain, registrar, dates and nameservers.
Advertisement