Introduction
Every HTTP request carries a User-Agent header that identifies the client software. Parsing it correctly is harder than it looks, because browsers deliberately misidentify themselves for compatibility. This tool dissects a User-Agent string into browser name and version, rendering engine, operating system, device type, and bot identity. It includes preset strings for common browsers and crawlers so you can test your detection logic. All parsing happens in your browser.
What this tool does
- Detect browser name and version, handling the ordering traps where Edge and Opera identify as Chrome first (Edge before Chrome, Opera before Chrome)
- Identify the rendering engine (Blink, WebKit, Gecko, or Trident) and its version from the UA string
- Extract the operating system and version, including Windows 10/11, macOS, Android, iOS, Linux, and Chrome OS
- Classify the device type as Desktop, Mobile, or Tablet, with vendor and model extraction for Apple devices and Android models
- Detect 26 common bots and crawlers (Googlebot, Bingbot, DuckDuckBot, Facebook Crawler, Twitterbot, AhrefsBot, SemrushBot, and more) with their documentation URLs
- Provide 13 preset User-Agent strings for quick testing, including Chrome, Firefox, Safari, Edge, Opera, Googlebot, Bingbot, cURL, and Postman
How this tool works
The tool applies a series of regex-based detection rules in a specific order to avoid misidentification. Bot detection runs first, because bots like Googlebot include `Mozilla/5.0` in their UA strings to bypass legacy browser checks.
For browser detection, the order matters. Edge includes `Chrome/` in its UA, so the tool checks for `Edg/` before `Chrome/`. Similarly, Opera includes `Chrome/`, so the tool checks for `OPR/` or `Opera/` first. Firefox is checked next, then Chrome (including `CriOS/` for iOS Chrome), then Safari. The tool distinguishes Safari from Chrome by checking for `Version/` combined with `Safari` and the absence of `Chrome/`.
Engine detection maps AppleWebKit to Blink (for Chrome/Edge/Opera) or WebKit (for Safari), based on the presence of `Chrome/`. Gecko is detected for Firefox, and Trident for legacy Internet Explorer.
OS detection uses specific patterns for each platform. Windows NT 10.0 maps to Windows 10/11 (the UA string does not distinguish them). macOS versions are extracted from `Mac OS X 10_15_7` style patterns. Android and iOS versions are extracted from their respective patterns.
Device detection checks for iPad, iPhone, Android Mobile, and generic Mobile indicators. Android tablet detection relies on the absence of `Mobile` in an Android UA string.
How User-Agent strings work (RFC 7231, RFC 9110)
The User-Agent header is defined in RFC 7231 and updated in RFC 9110, which specifies HTTP semantics. The header format is a product token followed by optional comments: `Product/Version (Comment)`. In practice, UA strings have evolved into a complex nesting of product identifiers and compatibility claims.
The historical reason for this complexity is the browser wars of the late 1990s and 2000s. Websites served different content based on the UA string, so new browsers included tokens from older browsers to avoid being blocked. Chrome's UA includes `Mozilla/5.0`, `AppleWebKit`, and `Safari` because sites checked for these tokens. Edge includes `Chrome/` and `Safari/` for the same reason. This is why parsing order matters so much.
Modern browsers are moving toward User-Agent Client Hints (UA-CH), defined in RFC 9110 and the Fetch standard. UA-CH provides structured `Sec-CH-UA` headers that are easier to parse and less prone to spoofing. However, the traditional UA string remains widely used and will not disappear soon.
Bot detection is important for analytics, ad fraud prevention, and access control. The tool identifies crawlers from major search engines (Google, Bing, DuckDuckGo, Baidu, Yandex), social media platforms (Facebook, Twitter, LinkedIn, WhatsApp, Telegram, Discord, Slack), and SEO tools (Ahrefs, Semrush, Majestic). Each detected bot includes a link to its documentation. For decoding tokens that may appear in UA-related data, see the JWT Decoder, Base64 Encode/Decode, and Hash Generator.
How to use this tool
- Paste a User-Agent string into the input field, or select a preset from the dropdown to load a common UA automatically
- The output shows the detected browser, engine, OS, device type, and bot status in a structured format
- If a bot is detected, the output includes the bot name and a link to its official documentation
- For mobile devices, the output includes the device type (Mobile or Tablet) and model where available
- Test edge cases by pasting UA strings from different browsers, operating systems, or API clients like cURL and Postman
- Use the preset dropdown to quickly compare how the parser handles Chrome vs Edge vs Opera, which all include `Chrome/` in their UA strings
Real-world examples
Detecting Googlebot for SEO crawl monitoring
Paste `Mozilla/5.0 (compatible; Googlebot/2.1; +http://www.google.com/bot.html)`. The tool detects Bot: Googlebot with a link to Google's crawler documentation. The device type is set to Bot. This lets you distinguish real visitors from search engine crawlers in your analytics pipeline.
Distinguishing Edge from Chrome
The Edge UA string `Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/120.0.0.0 Safari/537.36 Edg/120.0.0.0` contains both `Chrome/120` and `Edg/120`. The tool checks for `Edg/` first and correctly reports Microsoft Edge 120, not Chrome. Without this ordering, Edge would be misidentified as Chrome.
Extracting Android device model
Paste `Mozilla/5.0 (Linux; Android 14; Pixel 8) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/120.0.0.0 Mobile Safari/537.36`. The tool reports OS: Android 14, Device: Mobile, and extracts the model 'Pixel 8' from the parenthetical comment. This is useful for device-specific debugging in mobile web development.
Identifying an API client
Paste `curl/8.5.0`. The tool reports Browser: cURL 8.5.0 with no OS or device detected. This helps distinguish programmatic API access from browser traffic, which is useful for rate limiting and access control logic.
Comparison with similar methods
| Method | Complexity | Typical use |
|---|---|---|
| UA string parsing (this tool) | Regex-based, client-side, instant | Quick UA analysis, debugging, testing |
| UA-CH (Sec-CH-UA headers) | Structured headers, server-side | Modern browser detection, less spoofable |
| Server-side ua-parser library | Full regex database, npm package | Production analytics, server-side routing |
| DeviceAtlas or WURFL | Commercial device database | Enterprise device detection, ad targeting |
Limitations or considerations
User-Agent strings can be spoofed. Any HTTP client can set an arbitrary UA header, so UA-based detection should not be used as a security control. For security-critical decisions, combine UA detection with other signals like TLS fingerprinting or behavioral analysis.
The tool uses a fixed set of regex patterns. It may not detect very new browser versions or obscure browsers. For production use, consider a maintained library like `ua-parser-js` which is updated regularly with new UA patterns.
Device model extraction for Android is best-effort. The model string appears in the UA comment and varies by manufacturer. Some manufacturers include the model name, others include a code name, and some include nothing useful.
The tool does not detect browser capabilities (feature detection). For that, use JavaScript feature checks like `typeof fetch !== 'undefined'` rather than relying on UA parsing. Feature detection is more reliable and future-proof.
Frequently asked questions
Why does Chrome's User-Agent string contain 'Mozilla', 'AppleWebKit', and 'Safari'?
Historical compatibility. In the 2000s, websites checked for specific UA tokens to decide which content to serve. Chrome included these tokens to avoid being blocked by sites that only recognized Firefox or Safari. This practice continues today, making UA parsing a matter of checking tokens in the right order.
What is User-Agent Client Hints (UA-CH)?
UA-CH is a modern replacement for the UA string, using structured `Sec-CH-UA` HTTP headers. Instead of a single string, the browser sends separate headers for browser brand, version, platform, and mobile flag. UA-CH is easier to parse and less prone to the compatibility-driven complexity of traditional UA strings. It is supported in Chromium-based browsers.
Can I rely on User-Agent parsing for security?
No. UA strings are trivially spoofed. Any HTTP client can send any UA string. Use UA parsing for analytics, content adaptation, and debugging. For security decisions, use TLS fingerprinting, CAPTCHAs, or behavioral analysis instead.
How does the tool detect bots?
The tool checks the UA string against 26 regex patterns for known bots, including Googlebot, Bingbot, DuckDuckBot, Baiduspider, YandexBot, Facebook Crawler, Twitterbot, LinkedInBot, WhatsApp, TelegramBot, AhrefsBot, SemrushBot, and others. Each pattern maps to the bot name and a documentation URL.
Why is my browser version different from what the UA string shows?
Some browsers freeze the UA version string for compatibility. Chrome 120+ may report a frozen `Chrome/120.0.0.0` even in later versions. This is part of the UA freezing initiative to reduce UA-based fingerprinting. Check the actual browser version in the browser's settings, not the UA string.
Conclusion
User-Agent parsing is a practical skill for web developers, analytics engineers, and security analysts. This tool handles the ordering traps that make UA parsing tricky and includes bot detection for 26 common crawlers. For decoding tokens that appear in HTTP headers or API responses, see the JWT Decoder, Base64 Encode/Decode, and Hash Generator.