Network Tools

User Agent Parser

Parse browser User Agent strings to detect browser, OS and device.

User Agent String
📋 Common User Agent Examples
🔍

Enter User Agent string or use current browser UA

What is User Agent Parser?

User agent parser analyzes browser user agent strings to identify browser, OS, and device information.

Information Extracted

  • Browser name and version
  • Operating system
  • Device type (desktop, mobile, tablet)
  • Engine (Blink, Gecko, WebKit)

Use Cases

  • Analytics debugging
  • Device detection
  • Compatibility testing

A User-Agent parser splits the string a browser sends in the User-Agent header into browser name and version, operating system, device type, and rendering engine, and flags crawlers and mobile clients. Use it to see what trace your own browser emits, to debug analytics panels that mislabel traffic, or to check a suspicious crawler string before blocking it.

Parsing is a first-match regex ladder, not a scan for tokens

The component walks a fixed pattern list and returns on the first hit, so the order of that list decides the answer, not the order of tokens in the string. Edg/ is tested before Chrome/, which is why an Edge UA reports Microsoft Edge even though it also carries Chrome/120.0.0.0; MicroMessenger/ likewise sits ahead of Chrome/, so Android WeChat resolves to WeChat 8.0.x although the rest of the string is a Chrome 116 UA. Safari is placed last, plus an explicit skip whenever the string contains Chrome or Chromium. Engine detection uses a separate list starting with AppleWebKit/, so every Chromium browser reports WebKit 537.36: Blink has no token of its own.

Device type is decided by substring tests, not by the real platform

Device classification runs three tests in order: bot, then tablet, then mobile, with desktop as the fallback. The tablet test needs a keyword such as iPad or Tablet and also requires that no Mobile token appears, yet every iPad UA ships Mobile/15E148 — so the iPad sample built into the tool resolves to device type mobile while the OS row still says iPadOS 17.2. The mirror case: a Galaxy Tab UA containing SM-X710 has neither Tablet nor Mobile, so a genuine tablet is reported as desktop. Model extraction reads the text between ; and Build, so a string without that marker yields a model of nothing at all.

The versions shown are copied tokens, not measured facts

Several rows look wrong because the values are lifted straight from the string. Windows NT 10.0 maps to Windows 10/11 with an empty version, since Microsoft has kept the NT kernel number at 10.0 through Windows 11 — the UA cannot separate the two. Desktop Safari reports macOS 10.15.7 even on far newer releases because that token was frozen, and it reports the Safari build number (605.1.15) rather than the marketing version (17.2) that follows Version/. Chromium reduces its UA, so 120.0.0.0 is normal and the trailing zeros replace the real patch build. In Firefox, Gecko/20100101 is a hardcoded placeholder, not an engine release date.

Worked example

Parsing a real iPad UA

Input 
Mozilla/5.0 (iPad; CPU OS 17_2 like Mac OS X) AppleWebKit/605.1.15 (KHTML, like Gecko) Version/17.2 Mobile/15E148 Safari/604.1
Output 
Browser: Safari 604.1 | OS: iPadOS 17.2 | Device: mobile | Engine: WebKit 605.1.15

The OS row is correct because the iPad rule matches OS 17_2 and rewrites underscores as dots. The device row is not: the tablet branch demands a tablet keyword with no Mobile token, and iPad UAs always carry Mobile/15E148, so the string falls into the mobile branch. The browser version 604.1 comes from the Safari build token, not from Version/17.2.

Limits and pitfalls

  • Browsers that identify themselves with a vendor token the list does not contain (CriOS for Chrome on iOS, FxiOS for Firefox on iOS) skip down to the Safari/ row, so iPhone Chrome reads as Safari 604.1.
  • The /Linux/ rule is tested before the Ubuntu and Fedora rules, so a Firefox UA from Ubuntu always resolves to Linux with no version, and those two rows can never match.
  • Crawler detection is a plain case-insensitive substring search for tokens like bot and spider, so a CUBOT handset or any string containing robot is labelled a bot before device type is even computed.
  • There is no Blink branch in the engine list: Chrome, Edge, Opera and Samsung Internet all read WebKit 537.36, so that row cannot tell Chromium ports apart.
  • The UA is fully client-controlled and being frozen by vendors, and Safari still exposes no JavaScript replacement for it, so the parse is a hint for analytics, never an authentication or access-control signal.

Related tools

  • URL Parser — Parse URL components and edit query parameters.
  • HTTP Status Codes — Look up HTTP status codes and their detailed meanings.
  • IP Lookup — Look up IP geolocation, ISP, ASN and more.

When it goes wrong

I pasted five UAs from a log and the cards mix them: browser says Chrome, OS says iOS.

CauseNothing splits the textarea into lines. parseBrowser, parseOS, parseDevice and parseEngine each run one pass over the whole string and return at the first hit anywhere in it, so the four fields can come from four different lines; the only pre-processing is a single trim() around the entire input.

FixPaste one UA per check and read the copied result before moving to the next. To try a string shape, use the eight example buttons instead of stacking your own. For a file of UAs, loop over ua-parser in a script rather than through this page.

My API client sends curl/8.4.0; the tool answers Unknown Browser, Unknown OS, Unknown engine — and Desktop.

CauseNone of the fourteen browser or fifteen OS patterns matches a client that identifies itself by its own product token, and parseDevice ends with an unconditional return of type desktop when no bot, tablet or mobile keyword hits. "Nothing matched" and "a real desktop browser" therefore render identically.

FixWhen the browser row reads Unknown, treat all four rows as unset rather than as facts, and bucket that traffic as unidentified client in your own stats. A crawler or an HTTP library is not a desktop visitor.

Model shows SM-S918B, but the Brand row is missing completely.

CauseBrand is not read from the UA at all: it is a prefix match of the model string against a fixed twenty-name whitelist. Market codes such as SM-S918B, and product lines such as Pixel 8 Pro, begin with the code or the line name rather than with the vendor word, so brand stays undefined and the template hides that row.

FixRead the model as the identity: SM-S918B is a Galaxy S23 Ultra, NE2210 an OnePlus 10 Pro. A blank brand does not mean the phone was unrecognised. Filling it in needs a model-prefix table, which this page does not ship.

The Googlebot smartphone UA is tagged as a bot, yet the device pill right next to it says Desktop.

CauseThe bot regex is tested first in parseDevice and returns immediately, so the Android and Mobile tokens sitting in the same string never reach the mobile branch. The pill then renders from isMobile, which is true only for device types mobile and tablet — bot has no third state.

FixFor crawler traffic ignore that pill and read the string: Googlebot together with Mobile is the smartphone crawler, bare Googlebot/2.1 the desktop one. Any per-device crawl report has to be grouped from those tokens, not from isMobile.

When a regex ladder is enough, and when it is not

What you have in front of youThis parserWhat to reach for instead
One UA string, and you want the four fields read out loudThe page runs fourteen browser patterns and fifteen OS patterns inside the tab, sends no request, and keeps the raw string under the result so each row can be traced back to the token it came from.If the input is a file of UAs rather than one string, stop pasting: loop over it with ua-parser-js in Node or ua-parser in Python. Same first-match idea, but the pattern file has a version you can pin and diff.
You need to know which handset SM-S918B actually isThe model token is printed as found, with a brand prepended only when the model starts with one of twenty vendor names. There is no model-code to marketing-name table, so SM-S918B stays SM-S918B.That mapping only exists in a device database: uap-core regexes plus a device list, WURFL, or DeviceAtlas. Worth paying for when a report has to say "Galaxy S23 Ultra"; unnecessary when you only need phone versus desktop.
A visitor claims to be GooglebotMatching is a case-insensitive substring search whose list contains the bare word bot, so any client passes by typing those three letters into its header.Verify the network, not the string: reverse-resolve the IP to a googlebot.com or google.com name, forward-resolve it back, and compare the pair. The IP lookup on this site gives you the first half; the string alone proves nothing.
You want to branch UI or metrics on the parse resultAll four fields are copied from a client-supplied header that browsers are freezing and reducing, and the output carries no confidence value, so "Chrome 120" means the string said so.Test the capability, not the name: CSS.supports(), navigator.userAgentData high-entropy hints, or a plain feature check. Keep UA parsing for reporting only, where being wrong is survivable.
You have a month of access logs to classifyOne string per paste, rendered as cards, with no export. For a log of a hundred thousand lines that is a hundred thousand manual pastes.Write the ten-line script: split the quoted UA field out of each line, feed it to ua-parser, write CSV. Use this page to spot-check rows the script got wrong, not to produce them.

Frequently Asked Questions

How do I read a User-Agent string?
Roughly: product (system info) engine version. Seeing both "Chrome/126…" and "Safari/605…" in one UA is normal — Chrome declares Safari tokens for compatibility. This tool breaks the string into fields and identifies browser, engine, and device.
Can I still rely on UA for browser detection?
Not as the primary mechanism. UAs are spoofable and every major browser is freezing or reducing them; feature detection is the industry standard. UA is fine for analytics and soft hints, not for gating functionality.
Why do UA version numbers show as 0.0.0?
Chrome began freezing the UA (Reduced User-Agent) around version 120, zeroing minor versions to blunt fingerprinting; Firefox and Safari follow similar approaches. For precise versions use User-Agent Client Hints (the Sec-CH-UA header family), which the tool output notes.

Content reviewed: