Decode any user agent string, see every signal your own browser leaks, and build custom UA strings for Chrome, Safari, Android, curl and Googlebot.
This user agent parser decodes any User-Agent string into its component parts: browser name and version, rendering engine, operating system and version, device type, vendor and model, and CPU architecture. Paste a string, or click the button to load your own browser's User-Agent, and the breakdown appears instantly. Nothing is uploaded — parsing runs entirely in your browser using the ua-parser-js library.
User-Agent strings are notoriously unreadable by design. Decades of compatibility hacks left every modern browser claiming to be Mozilla, most claiming to be Safari, and Chromium-derived browsers claiming to be Chrome. A user agent decoder untangles that mess, which matters whenever you are debugging a device-specific bug, auditing analytics data, classifying crawler traffic in server logs, or checking what a rewritten UA string will look like to the receiving end.
Blink, Gecko, or WebKit.amd64 or arm64, when present.curl and Postman, and crawlers including Googlebot, Bingbot, GPTBot, and ClaudeBot.Take a typical Chrome-on-Windows string:
Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/120.0.0.0 Safari/537.36
Reading it left to right: Mozilla/5.0 is a historical fiction every browser still emits. The parenthesised section is the platform token — Windows NT 10.0 means Windows 10 or 11 (Microsoft never bumped the NT token past 10.0, which is why the parser cannot distinguish the two from the UA alone), while Win64; x64 gives the architecture. AppleWebKit/537.36 (KHTML, like Gecko) is another compatibility claim inherited from Chrome's WebKit ancestry. Chrome/120.0.0.0 is the only genuinely informative token, and the trailing Safari/537.36 is again pure legacy.
Derivative browsers append their own token at the end. Edge adds Edg/120.0.0.0, Opera adds OPR/106.0.0.0, Samsung Internet adds SamsungBrowser/23.0, and Vivaldi adds Vivaldi/6.4.3160.47. This is exactly why naive string matching fails: a substring search for “Chrome” matches Edge, Opera, Brave, Vivaldi, and Samsung Internet as well. A proper parser applies ordered rules so the most specific token wins.
The information available in a User-Agent string is shrinking. Chrome's User-Agent Reduction programme now freezes the minor version digits at 0.0.0, coarsens the platform version, and reports a generic model on Android rather than the real device. Apple has frozen much of the Safari string too. The practical consequence is that a UA string is no longer a reliable source of precise OS or device information.
The replacement is User-Agent Client Hints, a set of Sec-CH-UA request headers that servers must explicitly request and that the browser can decline. Low-entropy hints such as Sec-CH-UA, Sec-CH-UA-Mobile, and Sec-CH-UA-Platform are sent by default on secure origins; high-entropy hints such as the full platform version or device model require an explicit Accept-CH opt-in. Parsing a UA string remains the right tool for reading historical logs and for identifying non-browser clients, but for live feature decisions, feature detection beats both.
The parser flags strings matching bot, crawler, spider, scraper, curl, wget, Postman, Python, Axios, and node-fetch patterns. This is genuinely useful for triaging server logs, separating crawler traffic from human sessions in analytics, and confirming that an automated integration is identifying itself.
It is not, however, a security control. The User-Agent header is client-supplied text and can be set to anything. Any scraper that wants to look like Chrome simply says it is Chrome. Verifying a claimed crawler requires a reverse DNS lookup of the source IP followed by a forward confirmation — the process Google documents for Googlebot — which you can start with the IP geolocation lookup. If you are managing which crawlers you actually want, the robots.txt analyzer checks your directives are doing what you think.
The "About Your Browser" tab reads back every signal this page can see about the device you are on right now — not just the User-Agent string, but the wider set of values any site can collect without a permission prompt. That includes User-Agent Client Hints (brands, full version list, platform version, CPU architecture, bitness), screen resolution and device pixel ratio, viewport size, time zone and accepted languages, logical CPU core count and device memory, the GPU vendor and renderer string exposed through WebGL, the reported network type and round-trip time, and preference signals such as dark mode, reduced motion, forced colors, and Global Privacy Control.
Individually these values look harmless. Together they form a passive fingerprint: the tool computes a checksum over the collected values so you can reload the page and watch it stay identical. That stability is exactly what makes browser fingerprinting work without cookies. Everything is read and hashed locally and nothing is transmitted.
A few of these signals are worth knowing about on their own. navigator.webdriver reports whether the browser is under automation control by Selenium, Playwright, or Puppeteer, which is the first check most bot-detection services run. The WebGL renderer string frequently names the exact GPU model. And UA-CH platform version numbers do not match marketing names — Windows reports 13 or higher for Windows 11.
The "Build a User-Agent" tab works in the opposite direction: choose a client, platform, OS version, and version number, and it generates a syntactically correct User-Agent string. Use a user agent builder when you need to reproduce a device-specific bug, seed test fixtures or log parsers with realistic traffic, emulate a mobile device against a staging environment, or check how your server responds to a crawler.
Getting these strings right by hand is harder than it looks, because each browser family has its own shape. Chrome on Android needs a Mobile Safari suffix that Chrome on Windows must not have. Firefox uses an rv: token and a Gecko/20100101 stamp instead of the WebKit chain. Every browser on iOS and iPadOS is WebKit underneath, so Chrome and Firefox there identify as CriOS and FxiOS rather than Chrome and Firefox. Edge, Opera, and Samsung Internet append their own token to an otherwise complete Chrome string. Brave deliberately sends an unmodified Chrome User-Agent, so there is no Brave token to generate at all.
The builder covers browsers across Windows, macOS, Linux, ChromeOS, Android, iOS, and iPadOS, plus bots and command-line clients: Googlebot desktop and smartphone, Bingbot, GPTBot, ClaudeBot, curl, wget, Python requests, and Postman. Each generated string is immediately parsed back and the detected browser, OS, and device type are shown, so you can confirm the string will be read the way you intend before you use it. Ready-to-paste curl, wget, Node.js fetch, and Python requests snippets are generated alongside it.
One caveat: browsers block page scripts from setting the User-Agent request header, so a generated string can only be applied server-side, from a command-line client, or through your browser's DevTools device emulation.
It is the value of the HTTP User-Agent request header, a text line the client sends with every request identifying the browser, engine, operating system, and sometimes the device. Servers historically used it to tailor responses; today it is mostly used for analytics, logging, and diagnostics.
Click the button in the tool that loads your current browser's User-Agent, and it will be inserted and parsed immediately. You can also read it in a browser console by evaluating navigator.userAgent.
Yes. Switch to bulk mode and paste one User-Agent per line. Every line gets its own parsed row with browser, version, OS, OS version, device type, and any security warnings, and the whole table can be copied as tab-separated text straight into a spreadsheet.
Backwards compatibility. In the 1990s servers gated features on the Mozilla token, so every subsequent browser adopted it; Chrome inherited AppleWebKit and Safari tokens from its WebKit origins and kept them so that Safari-targeted code paths would still work. Those tokens carry no real information — the meaningful part is the Chrome/ token and any vendor token after it.
No. It is trivially spoofed, browsers deliberately reduce its precision, privacy extensions randomise it, and some clients omit it entirely. Use it for diagnostics and log analysis, never as an authentication or access-control signal.
Fields it cannot confidently identify are reported as unknown rather than guessed. Non-browser clients such as curl/7.68.0 or PostmanRuntime/7.29.2 parse cleanly as tools and are flagged by the bot detector.
The tool checks the parsed browser and OS against a list of end-of-life and outdated versions — Internet Explorer, legacy Edge, Windows XP through 8.1, and old Chrome, Firefox, Safari, Android, and iOS releases — and shows the EOL date where one exists. It is a heuristic based on version numbers, not a live vulnerability scan.
No. Parsing happens entirely in your browser. No User-Agent string you paste is transmitted or logged, which makes the tool safe for strings pulled from production logs. For a related client-side developer utility, see the SRI hash generator.
Open the "Build a User-Agent" tab, pick the client and platform, adjust the version, and copy the generated string. The tool applies the correct template for each browser family — the Blink chain for Chromium browsers, the Gecko chain for Firefox, and the WebKit chain for everything on iOS — then parses the result back so you can confirm it decodes correctly.
More than most people expect. Screen resolution, device pixel ratio, time zone, language list, CPU core count, approximate RAM, GPU model via WebGL, network type, and accessibility preferences are all readable without a permission prompt. The "About Your Browser" tab lists every one it can reach on your device and hashes them together to show how stable that combination is.
Not from this page. Browsers deliberately prevent scripts from overriding the User-Agent header. To change what your browser sends, use DevTools device emulation (Chrome and Edge: Network conditions), a browser extension, or pass the header explicitly from curl, wget, or your HTTP client of choice.
Decode user agent strings to identify browser, OS, device type, and bot status.
Analytics debugging, bot detection, device-specific testing.
Understanding bot traffic is essential for security, analytics, and resource management. Here's how to identify different types of automated traffic.
Search engine crawlers identify themselves clearly:
| Bot | User Agent Contains | Purpose |
|---|---|---|
| Googlebot | Googlebot | Google search indexing |
| Bingbot | bingbot | Bing search indexing |
| Slurp | Slurp | Yahoo search indexing |
| DuckDuckBot | DuckDuckBot | DuckDuckGo indexing |
| facebookexternalhit | facebookexternalhit | Facebook link previews |
| Twitterbot | Twitterbot | Twitter card generation |
Watch for these red flags:
python-requests/2.x or curl/7.xScrapy, HTTrack, wget# nginx example
if ($http_user_agent ~* (scrapy|wget|curl|python)) {
return 403;
}
Note: User agents can be spoofed. Use multiple signals for reliable bot detection.
User agent (UA) string is HTTP header sent by browsers/apps identifying themselves to servers. Format: "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 Chrome/120.0.0.0". Contains: browser name and version (Chrome 120), rendering engine (AppleWebKit, Gecko, Trident), operating system (Windows 10, macOS, iOS, Android), device type (desktop, mobile, tablet), sometimes: language, architecture (64-bit), brand (Samsung, Apple). Used for: analytics, feature detection, mobile optimization, bot detection, browser support warnings. Note: UA strings can be spoofed - not fully reliable for security. This tool parses UA strings into structured, readable information.
Historical quirk from browser wars. Netscape Navigator called itself "Mozilla" (Mosaic Killer). Early websites checked "if contains Mozilla" to serve advanced features. Internet Explorer wanted those features, added "Mozilla/4.0 (compatible; MSIE)" to UA string. Other browsers followed to avoid being blocked. Result: all modern browsers claim "Mozilla/5.0" for compatibility even though Netscape is long dead. Shows browser evolution: Mozilla/5.0 (compatibility) → actual browser (Chrome, Safari, Firefox) → rendering engine (WebKit, Gecko). Legacy from 1990s web, persists for backward compatibility. Ignore "Mozilla/5.0", focus on actual browser identifier. This tool extracts real browser name despite Mozilla prefix.
Check for mobile indicators in UA: "Mobile", "Android", "iPhone", "iPad", "iPod", specific devices (Samsung, Huawei). Desktop: "Windows NT", "Macintosh", "Linux x86_64". Tablets: "iPad", "Android" without "Mobile". Example mobile: "Mozilla/5.0 (iPhone; CPU iPhone OS 16_0 like Mac OS X) ... Mobile/15E148". Better approach: use JavaScript: navigator.userAgentData (modern), window.matchMedia("(max-width: 768px)") (responsive), navigator.maxTouchPoints > 0 (touch device). Challenges: UA strings unreliable (spoofed, fragmented), new devices constantly added, tablets sometimes report as desktop. This tool detects device type from UA with fallback indicators for edge cases.
Rendering engine converts HTML/CSS/JS to visual page. WebKit: used by Safari, older Chrome, many mobile browsers. Open source (Apple). Blink: Google's fork of WebKit (2013), used by Chrome, Edge, Opera, Brave. Most popular. Gecko: Firefox and Mozilla products. Independent codebase. Trident: legacy Internet Explorer (deprecated). EdgeHTML: legacy Edge (deprecated). Differences affect: CSS rendering (subtle layout differences), JavaScript performance, supported web features. For developers: test across engines, feature detection over browser detection, use caniuse.com for compatibility. UA strings show engine: "AppleWebKit/537.36" or "Gecko/20100101". Modern sites use feature detection, not engine sniffing. This tool identifies rendering engine from UA string.
Bots identify themselves in UA strings: Googlebot: "Googlebot/2.1", Bingbot: "bingbot/2.0", other crawlers: "Slurp", "DuckDuckBot", "Baiduspider", "ia_archiver" (Internet Archive). Social bots: "facebookexternalhit", "Twitterbot", "LinkedInBot". Monitoring: "Pingdom", "UptimeRobot". Good bots identify honestly. Bad bots: spoof browser UA to avoid detection, high request rate, ignore robots.txt. Detection strategies: check UA for known bot patterns, verify with reverse DNS (Googlebot IPs), rate limiting, CAPTCHA for suspicious patterns, analyze behavior (no JS execution, no image loading). Whitelist known good bots, block/throttle suspicious ones. This tool highlights bot identifiers in UA strings and provides bot detection patterns.
No - use feature detection instead of UA sniffing. Problems with UA: unreliable (can be spoofed), fragmented (thousands of variations), outdated quickly (new browsers, versions), doesn't detect actual capabilities. Better approach: JavaScript feature detection: "if ('geolocation' in navigator)", Modernizr library, @supports in CSS, progressive enhancement. Example: instead of "if UA contains Chrome", use "if ('IntersectionObserver' in window)". UA useful for: analytics (understanding user demographics), debugging (reproducing issues), serving different assets (mobile vs desktop HTML), blocking known bad bots. Use UA for stats, not for functionality decisions. This tool parses UA for analysis, not as replacement for feature detection.
User-Agent Client Hints (UA-CH) is modern replacement for UA strings. Instead of full string, server requests specific hints via headers: Sec-CH-UA (browser), Sec-CH-UA-Platform (OS), Sec-CH-UA-Mobile (mobile flag). Benefits: privacy (less fingerprinting), opt-in (server requests what it needs), structured (not parsing strings). Request hints: Accept-CH: Sec-CH-UA-Platform-Version (server header). JavaScript: navigator.userAgentData.getHighEntropyValues(["platform"]). Adoption: Chrome/Edge support (2021+), Firefox/Safari gradual adoption, UA string deprecated but remains for legacy. Migration: support both UA-CH and traditional UA parsing during transition. This tool parses traditional UA strings with note about UA-CH migration.
Spoofing = sending fake UA string. Reasons: privacy (avoid tracking), bypass restrictions (access desktop site on mobile), scraping (avoid bot detection), automated testing, emulation. Techniques: browser developer tools (change UA), browser extensions, curl/wget --user-agent flag, headless browsers (Puppeteer, Selenium). Detection: behavior analysis (bot-like patterns), canvas fingerprinting, TLS fingerprinting, JavaScript challenges, honeypot fields. Privacy tools: Tor Browser (standardized UA), Brave (reduced fingerprinting), privacy extensions randomize UA. For websites: don't rely solely on UA for security, combine with other signals, respect privacy settings. This tool shows what UA string reveals, highlighting privacy implications.