User Agent Parser & Client Audit
Deconstruct and analyze raw User-Agent strings. Real-time browser, OS, device, and rendering engine parsing with security audits and client capability checks.
Deconstruct and analyze raw User-Agent strings. Real-time browser, OS, device, and rendering engine parsing with security audits and client capability checks.
This tool is designed to provide a seamless experience for developers by handling complex operations directly in your browser with maximum speed and security.
A User Agent string is a text identifier that every web browser and HTTP client sends in the User-Agent request header with every single HTTP request it makes. It tells the server what software is making the request — the browser name and version, the operating system and its version, the device type, and the rendering engine. The server can use this information to serve different content or make different decisions based on what client is connecting.
The format of a User Agent string is notoriously messy — a consequence of 30 years of browser history and backwards compatibility requirements. A modern Chrome user agent looks 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 string starts with Mozilla/5.0 even though it is Chrome, references AppleWebKit (the Safari rendering engine), mentions KHTML (the predecessor to WebKit), says "like Gecko" (a Firefox reference), then finally identifies Chrome, and ends with a Safari version number. Every browser identifies itself as Mozilla for historical compatibility reasons, which is why raw user agent strings are nearly impossible to parse by eye without a tool.
The User-Agent header is sent with every browser request, every API call from an HTTP client library, every bot crawl, every automated test run, and every monitoring health check. It appears in your web server access logs, your CDN logs, your API gateway logs, and your application request logs. Understanding how to read it is a practical skill — knowing whether a bug report comes from Chrome on Windows versus Safari on iOS versus a headless Chromium bot changes how you investigate and reproduce the issue.
This tool takes any User-Agent string and parses it into its meaningful components. Paste the raw UA string and click Parse User Agent — you get the browser name and version, the operating system and OS version, the device class (Desktop, Mobile, or Tablet), and the rendering engine. These four categories cover what you actually need to know when debugging a browser-specific issue or analyzing who is accessing your application. The parser handles all major browsers: Chrome, Firefox, Safari, Edge, Opera, Samsung Internet, and their various platform-specific versions. It correctly identifies mobile browsers — Chrome for Android, Safari for iOS, Samsung Internet — and distinguishes them from their desktop equivalents. It also recognizes common non-browser user agents: Googlebot, Bingbot, and other search crawlers, curl and wget command-line tools, Postman and Insomnia API clients, and headless browsers like Puppeteer and Playwright that send Chromium-based user agents. The Full Raw String section at the bottom displays your input unchanged alongside the parsed output. This is useful when you want to copy a specific fragment of the raw string — for example the exact OS version string or the WebKit version number — for use in a regex pattern, a log analysis query, or a comparison against another UA string from your logs. The Copy String button copies the raw string back to your clipboard in one click.
1. Paste a User-Agent string into the User Agent String field — you can get this from your browser's DevTools (open DevTools, go to the Network tab, click any request, scroll to Request Headers, find User-Agent and copy its value), from your server access logs, from an API gateway log, or click Load Example to see a real Chrome on Windows user agent already populated.
2. Click Parse User Agent — the tool immediately extracts and displays the browser name and version, the operating system and OS version, and the device class (Desktop, Mobile, or Tablet) in the result cards at the top of the output section.
3. Read the parsed result cards — Browser shows the identified browser and version number, Operating System shows the OS name and version, and Device Class shows whether the client is a Desktop, Mobile, or Tablet device. If the tool shows Unknown for any field, the UA string uses a format the parser does not recognize — this is common for unusual bots, custom HTTP clients, or very old browser versions.
4. Check the Full Raw String section at the bottom — this displays your original input exactly as pasted. Use the Copy String button to copy the raw UA string back to your clipboard if you need to paste it elsewhere — into a regex pattern, a curl command, a test fixture, or a Slack message to a colleague.
5. Compare multiple user agents by clearing the field, pasting a different UA string, and parsing again — useful when you have several UA strings from your logs and need to compare what browser and OS each one represents, or when you are verifying that two different UA strings from the same device are being parsed the same way.
The most common situation where I reach for a UA parser is debugging a bug that only reproduces on specific clients. A user reports a layout issue. The bug report says "it is broken in Safari." But which Safari? Safari on iOS 16 on an iPhone? Safari on macOS Ventura on a MacBook? Safari Technology Preview? Each of these has different rendering characteristics. Copy the User-Agent from the request in your server logs, paste it here, and you know exactly which browser version and OS you need to test on to reproduce the issue. That specificity cuts investigation time from hours to minutes. The second scenario is log analysis. Web server access logs contain millions of User-Agent strings and reading them raw is useless. When I need to understand the distribution of browsers or devices hitting an API — for example to decide whether to drop support for a browser version, or to investigate a spike in traffic to understand if it is legitimate users or bots — I extract unique UA strings from the logs and parse them to categorize the traffic. Knowing that 40% of the traffic spike is from Googlebot or a specific version of Chrome tells me something very different about what is happening. The third use case is testing. When you are building a web application that serves different content or different layouts to different devices — a responsive layout, a different checkout flow for mobile, a different video player for iOS — you need to verify that your server-side UA detection logic is working correctly. Paste the exact UA strings from real devices into this tool to confirm they parse as the device class you expect, then use those same strings in your automated tests to verify your detection code handles them correctly.
Instant parsing of all major browsers — correctly identifies Chrome Firefox Safari Edge Opera Samsung Internet and their platform-specific mobile versions with exact version numbers
OS and version detection — identifies Windows macOS Linux Android and iOS with the specific OS version extracted from the UA string
Device class detection — correctly classifies the UA as Desktop Mobile or Tablet which is the key distinction for responsive design and server-side rendering decisions
Rendering engine identification — shows the underlying engine (Blink WebKit Gecko or Trident) which matters when debugging CSS rendering differences between browsers that share an engine
Bot and crawler recognition — identifies Googlebot Bingbot common scraping tools curl wget Postman and headless browser user agents so you can distinguish automated traffic from real users
Full raw string display — shows your original UA string alongside the parsed output with a one-click copy button
100% browser-based — your user agent strings are never transmitted to any server making it safe to paste UA strings from production logs that may contain sensitive request context
Works with any HTTP client UA — parses browser UAs API client UAs command-line tool UAs and custom application UAs not just standard browser strings
Identifying the exact browser and OS from a bug report to reproduce a browser-specific layout or JavaScript issue
Analyzing User-Agent strings from server access logs to categorize traffic by browser OS and device type
Verifying that server-side browser detection logic correctly identifies specific browser and device combinations
Distinguishing real user traffic from bot traffic in web server logs by identifying crawler user agents
Checking which browser version a QA tester was using when they reported a bug from a specific environment
Testing responsive design behavior by confirming which device class a specific mobile UA string maps to
Debugging API clients by identifying whether a request came from a browser a command-line tool or an automated test
Checking the User-Agent a third-party integration or webhook sender is using when making HTTP requests to your server
Example Input
Mozilla/5.0 (iPhone; CPU iPhone OS 17_2 like Mac OS X) AppleWebKit/605.1.15 (KHTML, like Gecko) Version/17.2 Mobile/15E148 Safari/604.1
Example Output
Browser: Safari 17.2 Operating System: iOS 17.2 Device Class: Mobile Engine: WebKit 605.1.15 Full Raw String: Mozilla/5.0 (iPhone; CPU iPhone OS 17_2 like Mac OS X) AppleWebKit/605.1.15 (KHTML, like Gecko) Version/17.2 Mobile/15E148 Safari/604.1
Invalid Format — Not a User Agent String: The tool expects a standard HTTP User-Agent header value. If you paste a full HTTP request, a URL, a JSON string, or any other text that is not a UA string, the parser will return Unknown for all fields or produce incorrect results. A valid UA string starts with the product token — typically Mozilla/5.0 for browsers — followed by parenthesized platform information and additional product identifiers.
Unknown Browser or OS: If the parser returns Unknown for the browser or OS, the UA string is from a client that uses a non-standard format not covered by the parser's pattern library. This is common for very old browser versions (Internet Explorer 6, Netscape), unusual embedded browsers, custom HTTP clients built with non-standard UA strings, or highly specialized IoT device agents. The raw string is still displayed so you can inspect it manually.
Empty Input: The tool requires at least some text in the input field to parse. If you click Parse User Agent with an empty field, no result is returned. Click Load Example to populate the field with a real Chrome UA string if you want to see how the parser works before testing your own strings.
Mobile Browser Showing as Desktop: Some mobile apps and progressive web apps send desktop UA strings intentionally — this is called UA spoofing and some apps do it to get the desktop version of websites. If a mobile device's UA is parsing as Desktop, the app or browser on that device may be sending a desktop UA by design. This is not a parser error — it is the parser correctly reading the UA the client chose to send.
Truncated UA String from Logs: Log aggregation tools sometimes truncate long strings. User agent strings — especially from modern browsers with many tokens — can exceed common truncation limits. If your parsed result looks incomplete or shows Unknown when you expect a specific browser, check whether the UA string in your logs has been cut off at a fixed character limit. Retrieve the complete UA string from the original request headers rather than the log entry.
Using User-Agent detection to serve different features instead of feature detection
Fix: UA-based feature detection — checking the browser name and version to decide whether to use a CSS property or JavaScript API — is fragile and breaks constantly as browsers update. The correct approach is feature detection: check whether the specific capability you need is available rather than which browser is running. In JavaScript, check if (typeof fetch !== 'undefined') rather than checking if the browser is Chrome. Use CSS @supports for CSS feature detection. UA detection is appropriate for analytics and bug investigation — it is not a reliable way to gate features in production code.
Assuming the UA string accurately represents the actual browser being used
Fix: User Agent strings are completely under the control of the client and can be set to any value. A developer testing with Postman can send any UA string they want. Browser extensions can modify the UA string. Privacy-focused browsers like Tor Browser send a generic UA to prevent fingerprinting. Some corporate proxies rewrite UA strings. A UA string tells you what the client claims to be, not what it actually is. For security decisions, never trust the UA string — it is useful for analytics and UX optimization but not for access control.
Blocking or restricting access based on User-Agent without considering legitimate use cases
Fix: Blocking requests based on UA strings — for example blocking all requests without a browser UA, or blocking specific browser versions — is a common but problematic approach. Legitimate API clients, monitoring tools, and accessibility software often send non-browser UAs. Screen readers, command-line tools used by developers to test your API, automated testing frameworks, and health check monitors all send non-browser user agents. Rate limiting and authentication are more reliable tools for access control than UA filtering, which is easy to bypass and blocks legitimate users.
Parsing User-Agent strings with a home-built regex instead of a dedicated library
Fix: User agent strings follow no single consistent format — they have evolved through 30 years of backwards compatibility requirements and browser wars. A regex that correctly parses Chrome on Windows will fail on Samsung Internet, iOS Safari, or a Chrome WebView inside an Android app. Use a maintained UA parsing library: ua-parser-js for JavaScript and Node.js, user-agents for Python, DeviceDetector for PHP, and UAParser for Java. These libraries maintain up-to-date pattern databases covering thousands of UA variants. This tool uses the same approach internally.
Not logging User-Agent strings in server access logs and then being unable to diagnose browser-specific production issues
Fix: The User-Agent header is almost always available in web server access logs but sometimes teams configure minimal logging that omits it. When a browser-specific bug surfaces in production — and it will — the ability to look up which UA was sending requests that triggered errors is invaluable. Make sure your Nginx, Apache, or application server logging configuration includes the User-Agent header. In structured logging, include the ua field explicitly. The cost of storing it is minimal and the debugging value when you need it is significant.
Git Cheatsheet
Quick reference guide for essential Git commands, branching workflows, remote repositories, stashing, and rollbacks.
Regex Cheatsheet
Interactive guide to Regex anchors, character classes, quantifiers, lookarounds, capturing groups, and search flags.
HTTP Headers Cheatsheet
Complete guide to standard and security HTTP headers including Authorization, CORS control, caching policies, and CSP directives.
SQL Cheatsheet
Complete guide to SQL statements including SELECT queries, WHERE filters, aggregate functions, JOIN types, and DDL commands.
What is a user agent string?
A user agent string is a text value sent in the User-Agent HTTP request header by every browser, HTTP client library, bot, and automated tool when it makes an HTTP request. It identifies the software making the request — the browser name and version, the operating system, the device type, and the rendering engine. Web servers receive this string with every request and can use it to serve different content or log which clients are accessing the service. The format is notoriously complex — modern Chrome identifies itself as Mozilla and references Safari and Gecko for historical backwards compatibility reasons, which is why a parser is needed to extract meaningful information.
Does it support all browsers?
Yes, all major browsers and most minor ones are supported: Chrome, Firefox, Safari, Edge, Opera, Samsung Internet, UC Browser, and their mobile-specific variants. The parser also recognizes common non-browser clients: Googlebot, Bingbot, and other search crawlers, curl and wget, Postman and Insomnia, and headless browsers like Puppeteer and Playwright. For very unusual or custom user agent strings not in the parser's pattern library, the tool returns Unknown for the unrecognized fields and displays the full raw string so you can inspect it manually.
Is it safe for sensitive data?
Yes. All parsing runs entirely in your browser using JavaScript — your user agent strings are never transmitted to any server, never logged, and never stored. User agent strings from production server logs can contain context about real user requests, so browser-based processing means that data stays on your machine. You can safely paste any UA string from your logs without concern about it being sent to a third-party service.
Why does Chrome say Mozilla in its User-Agent string?
This is a legacy of the browser wars of the 1990s and early 2000s. When Netscape Navigator dominated the web, websites served rich content only to browsers that identified as Mozilla. To ensure compatibility, Internet Explorer began identifying itself as Mozilla even though it was not. When other browsers followed, including Chrome and Safari, they all continued the Mozilla prefix to ensure servers did not serve them degraded content. Today, virtually every browser starts its UA with Mozilla/5.0 regardless of what it actually is, which is one of the main reasons raw UA strings are so confusing to read without a parser.
How do I get the User-Agent from my own browser?
The easiest way is to open your browser's DevTools (F12 or right-click and Inspect), go to the Network tab, click on any request to a website, scroll through the Request Headers section, and find the User-Agent field. Copy its value and paste it into this tool. Alternatively, you can open the browser console and type navigator.userAgent — this returns your browser's current user agent string directly. For mobile browsers, enable remote debugging via USB or use the Load Example button to see what a typical mobile UA looks like.
Can it detect bots and web crawlers?
Yes. The parser recognizes common bot and crawler user agents: Googlebot, Bingbot, DuckDuckBot, Baiduspider, YandexBot, Applebot, and other major search engine crawlers. It also identifies common scraping tools and HTTP clients like curl, wget, Python Requests, and axios. For headless browsers used in scraping — Puppeteer and Playwright — the UA typically looks like a standard Chrome UA but without the headless tag since modern headless Chromium mimics a real Chrome UA. Sophisticated bots intentionally send browser-like UAs to avoid detection, so UA-based bot detection is not foolproof.
How do I parse User-Agent strings in my server-side code?
For Node.js and JavaScript: use the ua-parser-js library — const UAParser = require('ua-parser-js'); const result = UAParser(request.headers['user-agent']); gives you browser, OS, and device objects. For Python: use the user-agents library — import user_agents; ua = user_agents.parse(request.headers['User-Agent']); gives you ua.browser.family, ua.os.family, ua.is_mobile, ua.is_tablet. For PHP: use DeviceDetector from Matomo. For Java: use UADetector or the uap-java library. For Go: use the mssola/user_agent package. All of these maintain regularly updated pattern databases that handle the full range of real-world UA strings.
Why does my mobile device's UA show up as Desktop?
There are a few reasons this happens. Some mobile browsers have a Request Desktop Site setting that sends a desktop UA intentionally so the server serves the desktop version of the website. Progressive web apps installed from the browser sometimes inherit a desktop UA. Some apps use a WebView with a customized UA that does not include mobile identifiers. Corporate MDM software can modify UA strings on managed devices. If you see a device you know is mobile parsing as Desktop, the device or app is intentionally sending a desktop UA — the parser is reading it correctly. Check the raw string for the absence of Mobile or Android or iPhone identifiers.
How to Optimize Website Performance Using Minification Tools (Complete Guide 2026)
How to optimize website performance using minification tools. Learn CSS, JS, HTML minification, real impact, best practices, and SEO benefits in 2026.
What is URL Encoding and Decoding Explained: Complete Guide 2026
What is URL Encoding and Decoding Explained: Complete Guide 2026. Learn how URL encoding works, encodeURI vs encodeURIComponent, when to encode, common mistakes, and real-world best practices.
Best Free Online Developer Tools You Should Use in 2026: The Ultimate List
Discover the best free online developer tools in 2026. Explore LearnHubly's privacy-first suite including JSON Formatter, Base64 Encoder, JWT Decoder, UUID Generator, SQL Formatter, and 60+ more tools. Boost productivity with zero-install, client-side utilities.
Recent Activity
No recent activity