User Agent Parser
Parse any User-Agent string to extract browser, OS, device type, and rendering engine.
Last reviewed: April 2026New to this tool? Click here for instructions
Paste any User-Agent string and instantly extract the browser, version, operating system, device class, and rendering engine — or detect your own current UA. Everything runs locally in your browser; nothing is uploaded or logged.
What This Tool Does
This tool takes a User-Agent string — the free-form identifier every browser, bot, and HTTP client sends in the User-Agent request header — and decomposes it into four structured fields: browser name and version, operating system and OS version, device class (Desktop, Mobile, Tablet, or Bot), and rendering engine (Gecko, WebKit/Blink, or Trident). The parser uses tiered regex matching against the established UA grammar fragments documented in RFC 9110 §10.1.5, ordered so that more specific product tokens (Edg, OPR, SamsungBrowser, Firefox) override the generic Chrome/Safari tokens that every Chromium and WebKit browser carries for legacy compatibility.
Three modes cover the common workflows. Parse accepts any pasted UA string. My UA reads navigator.userAgent from your current browser and runs it through the same parser — useful for confirming what your client reports to servers right now. Library ships 22 vetted reference UA strings spanning desktop browsers, mobile browsers, tablets, and major search-engine crawlers, all searchable and one-click loadable into the Parse field. Every parse happens client-side in vanilla JavaScript with no network calls. 🔒
How to Use It
The interface is three tabs at the top of the tool card; the workflow is identical inside each one.
Pasting and Parsing a UA String
Open the Parse tab (selected by default) and paste a UA string into the textarea. Parsing is debounced at 200 ms after the last keystroke, so the four result cards (Browser, OS, Device, Engine) update live as you type or paste. Click Try Example to pre-load the iOS Safari 17 string used as the worked example in the next section. Use Copy Result to copy the original UA string back to the clipboard — convenient when you want to keep the raw string alongside the parsed breakdown.
Detecting Your Own User-Agent
Switch to the My UA tab and the tool reads navigator.userAgent and renders both the raw string and the parsed fields. This is the fastest way to verify how your browser identifies itself after enabling UA spoofing in DevTools, switching between regular and Incognito mode, or testing a mobile emulator.
Browsing the Reference Library
The Library tab lists 22 canonical UA strings: Chrome, Firefox, Safari, Edge, Opera, Samsung Internet, and Linux Chromium on the desktop side; Chrome Android, Safari iOS, Firefox Android, and Samsung Internet on mobile; iPad and Android tablets; plus Googlebot, Bingbot, DuckDuckBot, Yahoo Slurp, Baiduspider, YandexBot, curl, and the Python requests library. Filter by typing into the search box (matches against device, browser, OS, and full UA). Click Use on any row to load that string into the Parse tab.
Worked Example: iOS Safari 17 on iPhone
Click Try Example and the following UA loads into the Parse field. We will walk through it token by token so you can see exactly which substring drives each output field.
Mozilla/5.0 (iPhone; CPU iPhone OS 17_2_1 like Mac OS X) AppleWebKit/605.1.15 (KHTML, like Gecko) Version/17.2 Mobile/15E148 Safari/604.1The diagram below shades each token region. The Mozilla/5.0 prefix is a compatibility relic kept by every modern browser; the iPhone token sets device; CPU iPhone OS 17_2_1 sets OS and version; AppleWebKit identifies the engine; Version/17.2 paired with Safari identifies Safari proper; Mobile flips the device class to Mobile.
Parsed result: Browser = Safari 17, OS = iOS 17.2.1, Device = Mobile, Engine = WebKit/Blink 605.1.15. The status bar reads Safari 17 - iOS 17.2.1 - Mobile.
Common Use Cases
Analytics Segmentation
Product and growth teams routinely segment funnels and conversion rates by browser, OS, and device class. Server-side logs and analytics platforms (GA4, Plausible, Matomo) all parse the UA on ingest and expose those facets as filters. When a dashboard shows an unexpected drop in "Safari iOS" conversions, validating the underlying UA strings against this tool is the fastest way to confirm whether the segmentation logic itself is correct or whether the dip is real. The same parser logic also catches misclassified bots polluting your numbers — Headless Chrome from synthetic monitoring (Datadog, Pingdom) often shows up as a regular Chrome user until you grep for HeadlessChrome.
Feature Detection Fallback
Feature detection (if ('IntersectionObserver' in window)) is always preferable to browser sniffing, but real-world bug-workaround code still occasionally needs to target a specific buggy browser-version range — for example, "Safari 14.0—14.0.3 has a known WebRTC bug." Parsing the UA is the standard escape hatch. Use it sparingly and pair every UA-gated workaround with a removal date in code comments so the branch dies when the affected versions drop below your support threshold.
Bot Filtering and Crawler Verification
Server-side rate limiting, fraud detection, and SEO audit tools all distinguish between human and crawler traffic. The Library tab lists the canonical UA strings for Googlebot, Bingbot, DuckDuckBot, Baiduspider, YandexBot, and Yahoo Slurp. For production code, never trust the UA alone — combine UA matching with reverse DNS verification against the search engine's published IP ranges, as Google documents in Verifying Googlebot.
Edge Cases and Limitations
The User-Agent grammar has accumulated enough exceptions over thirty years that any parser will hit edge cases. The ones below catch most people out.
UA spoofing is trivial. Chrome DevTools has had a built-in UA override since 2012 (Network conditions panel). curl accepts -A. Python's requests library accepts a headers={'User-Agent': ...} dict. Any HTTP client can send any string. The UA is a hint, never a security boundary.
Sec-CH-UA Client Hints are replacing the UA string in Chromium. Since Chrome 101 (2022), Chromium browsers freeze UA minor version numbers and unify OS/device tokens to reduce passive fingerprinting. The full information moves to Sec-CH-UA, Sec-CH-UA-Mobile, Sec-CH-UA-Platform, and Sec-CH-UA-Full-Version-List headers, which servers opt into via Accept-CH. See MDN: Client hints. Safari and Firefox have not adopted UA-CH, so cross-browser code still needs UA string parsing as a fallback.
The Mozilla/5.0 prefix is preserved purely for legacy reasons. Netscape Navigator 1.0 used the token Mozilla/1.0 in 1994. Servers began gating JavaScript and frame support on this token. Internet Explorer 3 then prefixed its UA with Mozilla/2.0 (compatible; MSIE 3.0; ...) to clear those gates. WebKit, Gecko, and Blink all preserve Mozilla/5.0 for the same reason today. Stripping it would break a long tail of 1990s-vintage server-side sniffing code that still runs in production somewhere.
iPad-on-macOS pretends to be desktop Safari. Since iPadOS 13 (2019), Safari on iPad sends a UA identical to desktop Safari on macOS — Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) .... Detecting iPad reliably now requires checking navigator.maxTouchPoints > 1 alongside the Macintosh token, since no real Mac (yet) ships with a touchscreen.
Googlebot detection requires more than a UA match. Malicious scrapers commonly forge Googlebot/2.1 in their UA to evade rate limits. Combine UA matching with reverse DNS (host followed by a forward lookup to confirm the result resolves back to a googlebot.com or google.com host).
Edge calls itself Edg/, not Edge/. Chromium Edge (2020+) uses Edg/120.0.0.0 — three letters — to avoid colliding with the legacy EdgeHTML token Edge/18.x. UA parsers that match Edge\/ with a trailing slash will silently misclassify modern Edge as Chrome.
Behind the Scenes
From NCSA Mosaic to Mozilla/5.0
The User-Agent header was introduced in 1992 with NCSA Mosaic, sending the minimal string NCSA_Mosaic/2.0 (Windows 3.1). Netscape Navigator launched in 1994 with the codename Mozilla (a contraction of "Mosaic killer") and adopted the Mozilla/1.0 token. When Internet Explorer arrived in 1995, server-side code already gated features on Mozilla, so Microsoft shipped Mozilla/2.0 (compatible; MSIE 3.0; Windows 95) — the first time one browser claimed to be another to clear compatibility gates.
The UA Reduction RFC
The current direction is documented in draft-ietf-httpbis-client-hints-uach (User-Agent Client Hints). Chromium freezes the UA string to a stable template and exposes the previously-embedded data through structured Sec-CH-UA-* headers that servers explicitly opt into. The motivations are passive fingerprinting reduction (the high-entropy bits no longer leak by default) and parser sanity (structured headers replace ad-hoc regex). Chrome announced the rollout schedule at chromestatus.com/feature/5704553745940480.
Why Every Browser Pretends to Be Every Other Browser
The layered claims (Mozilla/5.0 + AppleWebKit + KHTML, like Gecko + Chrome + Safari) are the historical record of which compatibility gates each new engine had to clear. Konqueror's KHTML claimed Gecko compatibility to clear Gecko-only gates; WebKit forked KHTML and inherited the claim; Chrome's Blink forked WebKit and inherited both; every Chromium-based browser today (Edge, Opera, Brave, Samsung Internet, Arc) ships the entire stack. The net result is a UA string that asserts kinship with every major browser engine of the last 30 years — an archaeological record more than an identifier.
Comparison: This Tool vs. UAParser.js vs. DeviceAtlas vs. WURFL
Several other tools and libraries parse User-Agent strings. The right choice depends on whether you need a quick visual sanity check, a JavaScript library for production code, or a commercially-maintained device intelligence database.
| Tool | Type | Fields Returned | Maintained By | Cost | Best For |
|---|---|---|---|---|---|
| This tool (ThisDevTool) | Web tool | Browser, OS, device, engine + library of 22 reference UAs | Solo maintainer | Free | Quick visual checks; pasting strings from log files |
| UAParser.js | JS library (MIT) | Browser, OS, device, engine, CPU architecture | Faisal Salman + community (since 2012) | Free | Production client-side and Node.js code; ~7 kB gzipped |
| DeviceAtlas | Commercial DB | 250+ device properties incl. screen, RAM, GPU | Afilias / Identity Digital | Paid (enterprise) | Ad-tech, telecom, anyone needing physical device specs |
| WURFL | Commercial DB + OSS edition | 500+ device capabilities; the OG mobile device DB (since 2002) | ScientiaMobile | Free tier + paid | Mobile-first apps needing detailed capability flags |
For most analytics and feature-detection-fallback use cases, this tool plus UAParser.js are the right pairing — use this page for one-off visual checks, drop UAParser.js into your bundle for production parsing. Reach for DeviceAtlas or WURFL only when you genuinely need physical device properties beyond what the UA string carries.
Frequently Asked Questions
What is User-Agent spoofing?
UA spoofing is the practice of sending a User-Agent header that misrepresents the client software making the request. Browsers expose this directly (Chrome DevTools → Network conditions → User agent), curl accepts -A, and scrapers do it routinely to bypass UA-based blocking. Because the UA string is just a request header under client control, it cannot be trusted as a security boundary — treat it as a hint, not an assertion.
What are User-Agent Client Hints?
User-Agent Client Hints (UA-CH) are an HTTP header set defined in draft-ietf-httpbis-client-hints-uach that replaces the monolithic User-Agent string with structured Sec-CH-UA, Sec-CH-UA-Mobile, Sec-CH-UA-Platform, and Sec-CH-UA-Full-Version-List headers. Servers opt in via the Accept-CH response header, and Chromium-based browsers send the requested subset on subsequent navigations.
How do I detect bots from a User-Agent?
Major crawlers self-identify in their UA strings — Googlebot/2.1, bingbot/2.0, DuckDuckBot, Baiduspider, YandexBot. The robust approach is to combine UA matching with reverse DNS verification against the crawler's published IP ranges (Google publishes googlebot.json). UA matching alone is insufficient because malicious scrapers commonly spoof Googlebot to evade rate limits.
Why is the User-Agent string so weird?
The UA string is an archaeological layer cake. Mozilla/5.0 is preserved from Netscape Navigator 1994 because servers used to gate frame and JavaScript support on it. AppleWebKit/537.36 (KHTML, like Gecko) is Apple's claim of KHTML lineage, kept so Gecko-targeted servers don't block WebKit. Every Chromium browser then carries Chrome/120.0.0.0 Safari/537.36 because WebKit-targeted sites in turn checked for Safari. It is layered backward compatibility going back three decades.
Will the User-Agent string still exist in 5 years?
Yes, but in reduced form. Chrome has been freezing UA minor version numbers and unifying OS/device tokens since Chrome 101 (2022), and the long-term plan documented at chromestatus.com/feature/5704553745940480 is a permanently frozen UA paired with Client Hints. Safari and Firefox have not committed to the same reduction timeline, so the legacy UA will remain meaningful for cross-engine analytics through at least 2028.
Should I use User-Agent Client Hints instead of the UA string?
For Chromium-only contexts, yes — UA-CH gives you structured fields (brand, version, mobile, platform, architecture, model, bitness) without regex parsing. For cross-browser analytics, you need both: Safari and Firefox do not send Sec-CH-UA headers, so you must fall back to UA string parsing for non-Chromium traffic. Most analytics libraries now do precisely this dual-path detection.
How does iPadOS pretend to be macOS?
Starting with iPadOS 13 (2019), Safari on iPad sends a User-Agent string identical to desktop Safari on macOS — Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7). Apple's stated goal was to make iPad receive desktop-class web pages. Detecting iPad reliably now requires checking navigator.maxTouchPoints > 1 alongside Macintosh in the UA, or reading Sec-CH-UA-Platform on Chromium-on-iPad (which is itself WebKit underneath).
Can I trust the User-Agent string?
For analytics segmentation and progressive enhancement, yes — it is correct most of the time. For security decisions (rate limiting, access control, fraud detection), no — the UA is client-supplied and trivially forged. Cross-reference with TLS fingerprint (JA3/JA4), behavioral signals, and IP reputation. The OWASP Application Security Verification Standard explicitly lists UA-only checks as an anti-pattern.