What Is My User Agent?

Built and tested by Pavel Ahmed · Last updated September 5, 2026

What Is a User Agent and What Does This Tool Do?

What does this tool do?

It reads the user agent string your browser exposes to JavaScript and breaks it into five fields: browser and version, operating system, device type, rendering engine and CPU architecture. The second half of the page does the same for any string you paste, so you can decode a line from a server log, a bug report or a screenshot without installing anything.

Why is this useful?

Raw user agent strings are deliberately messy. Every browser still starts with Mozilla/5.0 for compatibility with servers written in the 1990s, Chrome pretends to be Safari, Edge pretends to be Chrome, and version numbers are scattered across several tokens. Reading one at a glance is hard even for developers, so a parsed view is faster and less error-prone than picking the string apart by hand. It also matters when you need to know what a visitor really is: support tickets, layout bugs and suspicious log entries all start with this line.

Who uses this tool?

• Front-end developers: to confirm which engine is rendering a page before blaming a CSS bug on the browser.

• QA and support teams: to get an exact browser and OS from a user in one copy and paste, instead of asking a series of questions.

• Site owners reading server logs: to tell a real visitor from a crawler, a scanner or a script that forgot to set a header.

• Anyone testing a scraper or an API client: to check what header their own code is sending.

• Privacy-minded readers: to see how much a single header gives away before any cookie is set.

How Do You Use This Tool?

1. Open the page. Your current user agent appears in the first box automatically, with no button to press.

2. Read the parsed breakdown underneath it for browser, operating system, device, engine and CPU.

3. Press Copy to put the exact string on your clipboard for a bug report or support ticket.

4. To decode a different string, paste it into the box and press Parse, or the Enter key. Your own browser is not involved in that result.

5. Reuse a previous check from the recent checks list, which is stored in your browser only and cleared with the Clear button.

How Do You Read the Results?

The breakdown has five fields, all derived from the string itself.

How the Parse Is Worked Out

Every field in the breakdown is derived in your browser from the string alone. No request is made, no database is consulted, and pasted strings are never uploaded. What follows is the order the parser works in, and the specific decisions it makes when a string is ambiguous, because those decisions are what determine whether the row in front of you says Chrome 128 or Not identified.

1. Bots are checked before browsers

The very first pass scans for a fixed list of about twenty known crawler and command-line tokens by plain substring match: Googlebot, bingbot, Applebot, DuckDuckBot, YandexBot, Baiduspider, GPTBot, OAI-SearchBot, ClaudeBot, PerplexityBot, facebookexternalhit, Twitterbot, AhrefsBot, SemrushBot, curl, Wget, python-requests, axios, PostmanRuntime and HeadlessChrome. The first one that appears wins, and the browser detection is skipped entirely.

That order is not cosmetic. Googlebot sends a complete Chrome signature, so a browser pass run first would report Google Chrome 128 for a request that came from a crawler, which is exactly backwards when you are reading a server log. The reverse mistake is guarded too: if no named token matched but the string still carries a real browser signature — a Chrome/, Firefox/, Safari/ or one of the mobile equivalents — the parser does not fall through to Unnamed bot or crawler on the strength of the word "bot" appearing in some comment. Only when there is no real browser signature and the string mentions bot, crawler or spider anywhere does that label apply, and a crawler that sends no distinctive token of its own cannot be told apart from a browser by this header at all.

2. Browser tokens are tried from most specific to least

When the string is not a bot, browser detection runs an ordered list of token patterns, and the first one that matches produces the label. The order is fixed because most of these tokens can appear in the same string — an Edge string carries Chrome/ and Safari/ alongside its own Edg/, and a Chrome string carries Safari/ too. Testing for Safari/ first would label every Chrome user as a Safari user:

1. Edge — Edg/, EdgiOS/ or EdgA/
2. Legacy Edge — Edge/
3. Opera — OPR/ or Opera/
4. Samsung Internet — SamsungBrowser/
5. Yandex Browser — YaBrowser/
6. Vivaldi — Vivaldi/
7. Chrome on iOS — CriOS/
8. Firefox on iOS — FxiOS/
9. Firefox — Firefox/
10. Chrome — Chrome/
11. Safari — Safari/ alongside Version/
12. Internet Explorer — MSIE or the Trident/ token
13. Anything else that carries AppleWebKit — A WebKit browser, vendor not stated

Only the major version is reported, taken by splitting the matched version at its first dot, because the minor digits are the part Chromium now freezes and reporting 128.0.0.0 as a whole would suggest a precision the string no longer carries. A browser that reaches the end of the list with none of those tokens matched is reported as Not identified, not guessed at from the platform.

3. The operating system reads around three frozen tokens

Operating system detection walks its own ordered list, but the important part is what it refuses to state as fact. Three tokens in the wild are frozen by the browsers that send them, and each one is reported with an "or later" rather than the literal number:

Everything else is read literally when the string gives a version. Windows uses a lookup table so that 6.3, 6.2, 6.1, 6.0 and 5.1 resolve to the names people actually use — 8.1, 8, 7, Vista and XP respectively — rather than being printed as NT numbers. iOS and iPadOS pull their version out of the OS X_Y token with underscores turned back into dots, so 18_0 reads as iOS 18.0.

One ordering detail matters: the iPadOS check runs before the Mac check. An iPad set to request desktop sites sends a string containing Macintosh, and a Mac check run first would classify every such iPad as a Mac, which is precisely the false positive the FAQ entry warns about.

4. Device type is a heuristic, not a field

No user agent string ever says "desktop", so device type is inferred in a fixed order, and each step can only accept or fall through to the next:

1. A bot match from step one ends the matter: Bot or automated client.
2. TV and set-top tokens — SmartTV, AppleTV, HbbTV and similar — read as TV or set-top box.
3. iPad, Tablet, PlayBook or Silk reads as Tablet.
4. The Mobi token, or an iPhone, iPod, Windows Phone or Opera Mini token, reads as Mobile.
5. Android without Mobi reads as Tablet, since that is what Android sends when a device wants the full site.
6. A named desktop platform — Windows NT, Macintosh, CrOS, X11, Linux or one of the BSD names — reads as Desktop or laptop.
7. Anything left over is Not stated in the string, because guessing desktop for a string that names no platform is how a bare curl/8.4.0 ends up being reported as a desktop browser.

5. The engine has one hard override

Rendering engine detection looks for the classic engine tokens in order — Trident/ or MSIE first, then legacy Edge/, then anything that looks like Blink (Chrome, Chromium, Edg/, OPR/, SamsungBrowser), then Firefox/ or a Gecko version for Gecko, then a bare AppleWebKit for WebKit, then Presto. Each of those returns a fixed engine name.

There is one exception ahead of the whole list. Any string containing iPhone, iPad or iPod is reported as WebKit and nothing else, before any other engine token is even considered. That is not a shortcut around a gap; it is a fact about the platform. Every browser on iOS and iPadOS is WebKit under Apple's rules, so a CriOS string is Chrome on WebKit rather than Chrome on Blink, and the row reflects what is actually rendering rather than the vendor token.

6. CPU architecture is the weakest field, and admits it

CPU architecture is tested in this order: arm64 or aarch64 for ARM 64-bit, then the 64-bit x86 tokens (Win64, x86_64, amd64, WOW64, ; x64), then armv7 and arm for 32-bit ARM, then the 32-bit x86 tokens (i686, i386, WOW32). If none of them matched, the field is left as Not stated in the string rather than defaulted to any of the four, and two specific cases are called out instead of being passed off as facts: Safari reports Intel Mac OS X on Apple silicon Macs as well as on Intel ones, and iPhones do not state an architecture in their user agent at all.

Two different blanks, deliberately kept apart

When a row reads blank, the reason is always one of exactly two things, and the wording distinguishes them because they mean different things. Not stated in the string is what a field says when the string is present and simply does not carry that information: an iPhone that omits its CPU, a Safari string that reports Intel on an M-series Mac. No user agent string was reported is what every row says when the browser exposed nothing at all — the fetch returned an empty string, usually because of a privacy extension or a locked-down environment — and the second message is about a silence where the first would be about a stated absence.

One further source is kept separate on purpose. Where your browser supports User-Agent Client Hints, the note under the string reports what navigator.userAgentData exposes, but none of the five parsed rows read from that source. It is a different signal with different rules, deliberately reduced by the browser vendors, and mixing it into the string parse would make the two indistinguishable in the output.

When Would You Use This Tool?

How Does a Parser Identify the Browser?

Each browser family marks itself with a token that the others do not use, which is what a parser looks for. The patterns below follow MDN's browser detection reference, which also explains why detection by user agent should be a last resort behind feature detection.

How Does a User Agent Differ From IP and Cookies?

These three are often confused, and they answer different questions. The user agent describes the software: browser, engine, platform. Your IP address describes the connection: which network you are on and roughly where it is registered, which is what an IP lookup reads, and what a VPN check examines. A cookie is storage a site sets on your device to recognize a return visit.

Only the cookie needs consent in most jurisdictions, because the other two are sent automatically as part of making the request at all. That is also why changing your user agent does not make you anonymous: your address still arrives with every request, and vice versa. If you want to reduce what a site can infer, both have to be handled, and neither is handled by this tool. It only shows you what is already being sent.

What Other Tools Work With This One?

Frequently Asked Questions