User Agent Parser

Decode the compatibility story inside a User-Agent string

A User-Agent string is an HTTP request-header value that identifies, or claims to identify, client software. Browser strings accumulated compatibility tokens over decades, so they often read less like clean device metadata and more like historical negotiations: Mozilla/5.0, platform comments, an engine token, browser product, and version markers can coexist even when several labels are not literally true.

This user agent parser uses local regular expressions to estimate browser, version, operating system, device class, rendering engine, CPU architecture, brand, and model. On load it reads navigator.userAgent and parses the current browser. You can paste another string or choose one of four presets for Chrome on Windows, Safari on iPhone, Firefox on macOS, and Googlebot.

No remote parser or fingerprinting API is called. Input stays in React state, and parsing runs in the browser. Use Current Browser UA restores the originally captured string. Copy writes the current text through the Clipboard API.

Read one string by hand

Consider the included Chrome preset:

Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/120.0.0.0 Safari/537.36

The parser sees Windows NT 10.0 and reports Windows version 10 / 11; conventional User-Agent data cannot reliably distinguish those releases. x64 becomes x64 (64-bit). AppleWebKit/537.36 first identifies an engine token, but the presence of Chrome changes the displayed engine name to Blink while retaining the matched WebKit token’s version. Chrome/120.0.0.0 supplies browser version and major version 120.

Because no mobile, tablet, or bot marker matches, device type defaults to Desktop. That does not prove the machine is physically a desktop. A laptop, kiosk, virtual machine, or spoofing client can produce the same category.

The string ends in Safari/537.36, but the parser checks Chrome before Safari and requires Safari’s Version/...Safari pattern. Compatibility tokens are why naïvely searching for the word Safari gives poor results.

How this parser classifies clients

Bot classification runs first using terms including bot, googlebot, crawler, spider, robot, and crawling. Tablet markers are checked before the broader mobile outcome in the final branch, although the tool computes both. Mobile markers include Mobi, Android, iPhone, iPod, BlackBerry, IEMobile, and Opera Mini. Everything else is labeled Desktop rather than Unknown.

Browser detection checks Edge, Opera, Vivaldi, Brave, UC Browser, Yandex, DuckDuckGo, Chrome, Firefox, Safari, Internet Explorer, Googlebot, and Bingbot in that order. Order matters because Chromium-based products often include Chrome. Some products do not expose their brand token, so a specialized browser can be reported as Chrome.

OS parsing recognizes Windows NT versions, macOS, Android, iOS, Linux, and ChromeOS. Windows NT 10.0 maps to 10 / 11. Underscores in Apple OS versions become dots. User-Agent reduction and platform conventions can freeze or generalize these versions.

CPU output depends on tokens such as x86_64, x64, WOW64, AMD64, i386, x86, AArch64, ARM64, or ARM. Missing information becomes Unknown. An architecture token may describe compatibility mode rather than physical hardware.

Android model parsing takes text after the Android version up to a semicolon or closing parenthesis, trims an optional Build/ suffix, and guesses the first word as brand. This heuristic can mistake locale or vendor formatting for model data. Apple iPhone and iPad strings receive Apple brand and broad model labels, not exact hardware generations.

Use presets as parser test cases

Select Safari / iPhone to see iOS, Apple iPhone, a Mobile device class, Safari version from the Version/ token, and an AppleWebKit engine match. The exact CPU is usually absent. This demonstrates that unknown architecture is not a parser failure; the string simply does not disclose it.

Select Firefox / macOS. Gecko and Firefox tokens produce a different engine and browser family, while Mac OS X 10_15 becomes macOS 10.15. Real modern macOS strings may intentionally report stable platform versions rather than the user’s exact release.

Select Googlebot (SEO Crawler). The bot expression classifies it as Bot, and Googlebot/2.1 identifies the named client. Anyone can paste or transmit that text. Real crawler verification requires DNS and network checks documented by the crawler operator, not a string match.

Presets are static historical examples. Their version numbers do not update to current browser releases, and choosing one does not emulate that browser, change request headers, resize the viewport, or alter server behavior. It only replaces text in the parser.

Debugging with a parsed User-Agent

When a user reports a rendering issue, ask for the complete string and the actual browser version from the product’s About screen. Paste the string to get an initial family and OS estimate. Reproduce at the relevant viewport and input mode; User-Agent alone does not reveal CSS pixel ratio, touch support, feature flags, enterprise policy, GPU, extensions, or accessibility settings.

For server logs, compare the parser result with route, timestamp, status, latency, and Client Hints if available. Grouping by major browser can help triage, but preserve an Unknown bucket. A parser update can change historical classifications even when raw logs remain constant, so analytics pipelines should version their parsing rules.

For an API returning the wrong content, inspect server-side UA branching. Feature detection, responsive design, and progressive enhancement are generally more robust than browser-name checks. If an unavoidable workaround exists, make it narrow, tested, temporary, and resilient to missing or misleading tokens.

User-Agent Client Hints and reduction

Browsers increasingly reduce high-entropy information in the legacy User-Agent header to improve privacy and compatibility. Chromium’s User-Agent Client Hints expose selected data through Sec-CH-UA request headers and the navigator.userAgentData API, subject to browser support and server opt-in for higher-entropy hints.

This component does not read Client Hints or userAgentData. It parses only the textarea string. Therefore a generic platform or frozen version is expected on some browsers. Do not “correct” an unknown field by inferring details the client intentionally withheld.

Client Hints are not universal and still should not become a fingerprinting wish list. Request only information required for a concrete function, account for permissions and caching through Vary, and provide behavior that works when hints are absent.

Privacy and fingerprinting considerations

The current User-Agent comes from a standard browser property and remains local to the component. Pasted strings are not sent to a lookup service. The page performs no fetch based on the input. Copy invokes navigator.clipboard.writeText, normally following a click and subject to secure-context or browser permission rules.

A User-Agent can still be personal or operational data when combined with IP address, timestamps, account identifiers, rare device models, or other signals. Minimize collection, define retention, restrict access, and avoid publishing raw log excerpts. Local parsing reduces disclosure to a parsing vendor but does not remove responsibilities around the source data.

Do not use this result as an authentication factor, fraud verdict, or reliable bot control. User-Agent strings are trivial to spoof. Strong decisions need appropriate authentication, authorization, behavioral controls, rate limits, and, where justified, verified network identity.

Known interpretation traps

An iPad configured to request desktop sites can resemble macOS. Embedded webviews may omit familiar browser tokens. Privacy browsers can intentionally imitate a mainstream browser. Headless automation may use a normal-looking string. Compatibility layers can report x86 on ARM hardware. This parser cannot resolve those ambiguities.

Engine naming is also approximate. The component changes AppleWebKit to Blink only when it finds literal Chrome or Chromium. Edge, Opera, and other Chromium-derived strings can consequently be identified correctly as browsers while the engine card still says AppleWebKit. Engine version displayed beside Blink may be the AppleWebKit compatibility version, not a standalone Blink release.

ChromeOS parsing has an edge case: the Linux branch runs before a later standalone ChromeOS branch but changes the name when CrOS is present, so ordinary ChromeOS strings still work. Unusual token arrangements may not. Browser parsing is heuristic text processing, not device attestation.

The parser labels an empty or unrecognized non-mobile string as Desktop with unknown details. “Desktop” therefore sometimes means “none of the mobile, tablet, or bot patterns matched.” Read Unknown fields honestly.

Troubleshooting unexpected output

First confirm the entire User-Agent was pasted without line breaks, log prefixes, quotation marks, or escaped characters. Search for the browser’s distinctive token: Edge uses Edg/, iOS Chrome uses CriOS/, and iOS Firefox uses FxiOS/. A product absent from the built-in ordered list may fall through to its compatibility family.

If the browser version says Unknown, the product token may have no slash-version pattern expected by the regular expression. If OS version is Unknown, the string may intentionally omit it. If reset is disabled, the textarea already equals the UA captured when the component mounted.

When the current result disagrees with the device, compare navigator.userAgent directly in DevTools and account for browser settings or extensions that modify it. This page reports what the string says according to its rules, not what hardware inspection would prove.

Questions about UA parsing

Can the parser identify an exact iPhone model?

No. Typical browser User-Agent strings expose iPhone as a family, not a dependable hardware generation. This tool reports Apple and iPhone only.

Why does Windows show “10 / 11”?

Both commonly present Windows NT 10.0. Distinguishing them requires another supported signal and should degrade gracefully when unavailable.

Can I use the Bot label to block crawlers?

No. It is a keyword match and is easily spoofed in either direction. Use layered abuse controls and operator-specific verification where needed.

Does selecting a mobile preset make the website mobile?

No. It changes parser input only. It does not emulate touch, viewport, network conditions, or request behavior.

Why is Brave sometimes reported as Chrome?

Not every Brave context includes a Brave/ token. Chromium compatibility text then matches Chrome. Similar ambiguity affects many derived browsers.

Is parsing performed on a DevsTool server?

No. Regular expressions run locally in the browser, with no component network request.