User-agent parser

Parse a user-agent string into browser, OS, device, and more

All computation runs locally in your browser

Last updated: February 4, 2026

CreatorFrank Zhao

User agent string

Browser

Name

No browser name available

Version

No browser version available

Engine

Name

No engine name available

Version

No engine version available

Name

No OS name available

Version

No OS version available

Device

Type

No device type available

Vendor

No device vendor available

Model

No device model available

CPU

Architecture

No CPU architecture available

Introduction / overview

The User-agent parser takes a UA string (the value of the User-Agent HTTP header) and extracts the most useful “human fields”: browser, rendering engine, OS, device, and CPU architecture.

UA strings are helpful for debugging and analytics, but they’re not a perfect identity signal. They can be spoofed, truncated, or intentionally reduced.

Who is this for?

Developers debugging “works on my machine” issues across browsers.
Support teams interpreting logs and reproducing customer environments.
Analysts QA-ing segmentation rules (mobile vs desktop, OS families, etc.).

Privacy note: parsing is done locally in your browser. If you paste a UA string from logs, treat it as potentially identifying data.

If you’re working on device-level checks, you might also like Device information or if you’re handling URLs and query params, pair this with URL parser and URL encoder.

How to use / quick start

1Paste a UA string into the input box. If you leave it empty, the tool auto-fills your current browser’s UA.
2Review the parsed cards: Browser, Engine, OS, Device, and CPU.
3Use Share to send a link that includes the UA input, or Favorite if it’s a UA string you reuse.
4Use Reset to clear the custom input and go back to the auto-detected UA.

Mini worked example: share-link size sanity check

Share links can include your UA input (as a query parameter). Let $L$ be the UA length (characters) and $M$ be the maximum length we include in a share link.

L \le M

=

180 \le 6000

\Rightarrow

\text{OK to include}

In practice: if your UA is extremely long (or you pasted extra log context), the share link may omit the UA. When that happens, share without results and paste the UA separately.

Quick interpretation tip: “Browser” is the user-facing product name, while “Engine” is the rendering core (e.g., Blink/WebKit/Gecko). If those don’t match your expectations, the UA might be spoofed or simplified.

Real-world examples / use cases

1) Reproducing a customer bug

Background: a user says “the page is broken” but it works for you. Input: paste their UA string from a support ticket.

Result: you identify browser family and OS version. If you find it’s an older Safari, you can prioritize a compatibility fix.

Application: use the result to pick the right test device or emulator.

2) Bot vs human traffic hints

Background: you see unusual spikes in traffic. Input: UA strings from suspicious requests.

Result: you spot obvious automation markers or generic UA formats.

Application: treat this as a hint, not proof—combine with rate limits, behavior signals, and server logs.

3) Validating analytics rules

Background: you have segmentation rules like “mobile Safari” or “Android Chrome”. Input: a sample of real UA strings.

Result: you compare your rule outputs against parsed results. If $n=20$ samples disagree on $k=3$ cases, that’s a disagreement rate of $k/n = 3/20 = 0.15$ .

Application: tighten rules or add exceptions where it matters.

4) Launch readiness checks

Background: you’re about to ship a UI change. Input: UA strings for your top browser/OS combinations.

Result: you quickly confirm coverage (desktop + mobile) and prioritize real-device testing.

Application: combine with responsive checks and feature detection.

Common scenarios / when to use

Log triage

Turn raw UA strings into readable environment labels.

Desktop vs mobile split

Spot device type hints and validate your targeting rules.

Device-specific issues

Identify OS families (iOS/Android/Windows/macOS) fast.

Compatibility planning

Check if a UA points to legacy browsers needing fallbacks.

Sharing reproducible context

Send a share link so teammates see the same input.

Security investigations (lightweight)

Use UA as one weak signal alongside better telemetry.

It may be a poor fit when:

You need high-confidence device identity (UA can be spoofed or reduced).
You need feature support decisions (use feature detection, not UA parsing).
You’re dealing with privacy-sensitive contexts; minimize UA sharing and retention.

Tips & best practices

Treat UA as “best effort” metadata
Use it to guide debugging and reporting, not to grant access or enforce security.
Prefer feature detection for compatibility
Browsers evolve. If you’re deciding whether a feature exists, test the feature, not the UA.
Keep a “known UAs” snippet list
Favorite a few representative UAs (iOS Safari, Android Chrome, desktop Chrome/Firefox) to speed up QA.
Share responsibly
UA strings can be identifying. Avoid posting them publicly when you don’t need to.

Pro tip: if you’re building share links with UA included, run it through URL encoder when you need a safe, copy-pastable version.

Calculation method / formula explanation

UA parsing isn’t a numeric calculation—it’s pattern matching. Conceptually, you can think of the parser as a function that maps a raw string into a structured result.

Conceptual model

\mathrm{Result} = f(\mathrm{UA}) = (\mathrm{browser},\ \mathrm{engine},\ \mathrm{os},\ \mathrm{device},\ \mathrm{cpu})

(a structured summary extracted from the UA string)

Variables used in this guide

$\mathrm{UA}$ = the raw user-agent string
$L$ = UA length (characters)
$M$ = max shareable length (characters)

Related concepts / background info

Browser vs engine

The “browser” is the product users recognize (Chrome, Safari, Firefox). The “engine” is the rendering core. Many browsers share the same engine, which is why engine detection can matter for rendering quirks.

User-Agent reduction & Client Hints

Modern browsers are reducing UA detail for privacy. Some environments use User-Agent Client Hints(UA-CH) for more structured, permissioned data.

Why parsing can be wrong

UA formats are not fully standardized across all apps. Some UAs include compatibility tokens, some are customized, and some are intentionally generic.

If you also need to validate content types or file signatures, check MIME types.

Frequently asked questions (FAQs)

Does this tool send my UA to a server?

No. Parsing runs locally in your browser. Sharing can put your UA into a URL, so treat share links like any link containing potentially sensitive data.

Why do I see “No device model available”?

Many desktop UAs don’t include a specific model, and modern mobile UAs may intentionally hide it. “Missing” does not mean “unknown device”—it often means the UA simply doesn’t carry that detail.

Can I detect iPad vs iPhone reliably from UA?

Sometimes, but not always. iPadOS and iOS have overlapping formats. For high-confidence behavior changes, prefer responsive design + feature detection.

Is UA parsing safe for access control?

No. UAs can be spoofed. If you need authentication/authorization, use real auth (tokens, sessions, etc.).

What’s the difference between browser version and engine version?

A browser can update independently of its engine, and some browsers share an engine. When debugging rendering, the engine version can be the more relevant field.

Why does the share link sometimes not include the UA?

To keep URLs reasonable, we only include UA inputs up to a limit. Conceptually, if $L > M$ , the tool may omit the UA from the share URL.

How do I interpret CPU architecture?

It’s an optional hint (e.g., x86, x64, arm). Many UAs don’t include it, and some environments report generic values.

What should I do if the result looks wrong?

Try a second UA sample from the same environment, and consider whether the UA was truncated or modified. For platform decisions, validate with real devices or feature checks.

Limitations / disclaimers

UA strings are not identity

UA parsing should not replace authentication, fraud prevention, or device attestation. It’s a convenience layer for debugging, reporting, and coarse analytics.

Spoofing & privacy changes

UAs can be spoofed by extensions, proxies, bots, and automation frameworks. Browsers also reduce UA detail over time, which can change parsing results even when users didn’t “change devices”.

Not professional advice

If you’re making compliance, security, or legal decisions, consult professionals and rely on stronger signals than UA strings.

External references / sources

Related Calculators

Chronometer

Use a simple chronometer (stopwatch) to track elapsed time down to milliseconds. Runs locally in your browser.

Try Now

Email normalizer

Normalize email addresses to a standard format for easier comparison. Useful for deduplication and data cleaning. Runs locally in your browser.

Try Now

ETA calculator

Estimate the time needed to consume a total amount at a constant rate, and get an expected end time. Runs locally in your browser.

Try Now

JWT parser

Parse and decode your JSON Web Token (JWT) and display its content. All computation runs locally in your browser.

Try Now

MIME types

Know which file extensions are associated to a MIME type, and which MIME type is associated to a file extension. Includes a full MIME types table.

Try Now

Lorem ipsum generator

Generate random Lorem Ipsum placeholder text with customizable paragraphs, sentences, and word counts. Runs locally in your browser.

Try Now