What is my user agent?

How this check works

Every HTTP request your browser sends includes a User-Agent header. It is a plain text line, and this page reads it from your request and shows it exactly as received. There is no script involved in that step; the string is visible to every site you visit, every CDN in front of those sites and every proxy in between.

The page then parses the string into fields:

• Browser and version, by matching the product tokens in order of specificity. Many browsers include the tokens of the engines they are built on, so Edge contains Chrome, which contains Safari; the parser checks the most specific name first.
• Engine, derived from the browser: Blink for Chromium browsers, Gecko for Firefox, WebKit for Safari and for every browser on iOS, where Apple requires WebKit.
• Operating system and version, from the platform tokens, with the caveats described below.
• Device type: desktop, mobile, tablet or bot, from tokens such as Mobile, iPhone, iPad and tablet model names.
• Bot detection, by matching the string against a list of search engine crawlers, SEO tools, AI crawlers, social media link fetchers, command-line clients and headless browsers.

For your own request, the page also shows the client hint headers your browser sent and the Accept-Language list, because those two complete the picture that the user agent alone no longer gives. For a pasted string, only the parse is shown, since there are no accompanying headers.

A pasted string is accepted up to 2,000 characters; control characters are stripped, and the lookup is logged with a one-way hash of your address and the first 120 characters of the string, kept for 30 days for abuse prevention. The same parse is available as JSON for scripts that need to classify user agents from a log file.

How to read your result

A few common strings, read the way the parser reads them:

• A string containing Windows NT 10.0, then Chrome with a version, then Safari, is Chrome on Windows 10 or 11; the Safari token is a compatibility leftover.
• A string containing iPhone, CPU iPhone OS with a version, and Safari with a Version token is Safari on an iPhone; the same with CriOS instead is Chrome on an iPhone, still on the WebKit engine.
• A string containing Android, Mobile and Chrome is Chrome on an Android phone; without Mobile it is a tablet or a desktop-site request.
• A string containing Macintosh and Firefox with a Gecko token is Firefox on a Mac.
• A string that is just a tool name and version, such as a command-line client, is not a browser; the device type shows bot and the anonymity score deducts 20 points for automation signals.

If the browser, engine and operating system agree with the client hints and with what you know you are using, the string is honest. If they disagree, something is rewriting it: an extension, a privacy setting, a corporate proxy or an antidetect profile.

How to fix it

What you might want to change, and how:

Update an old browser. An out-of-date version in the user agent is rare and marks the browser as unusual, and old browsers are also the ones with known security holes. Update from the browser's own menu; the version shown here changes on the next load.

Stop an extension from altering the string. If the parsed browser or system is not what you are using, open the extensions page and look for user-agent switchers, privacy tools or developer tools with an override. Disable them for the profile you use for logins. Then reload this page and compare the user agent with the client hints; they should describe the same browser.

Match the string to the setup behind a proxy. The user agent should name a platform that fits the rest of the fingerprint and the IP. A Windows user agent on a profile whose client hints, WebGL renderer and fonts say macOS is a contradiction; so is a mobile user agent with a 2560 by 1440 screen. Antidetect browsers that generate the string together with the other values avoid this; hand-edited strings usually do not. Verify on the browser fingerprint page.

Set the string in a script deliberately. If you write code that fetches pages, send a user agent that identifies your tool and gives contact information, and expect sites to treat it as automation. Pretending to be a browser from a script is detectable through the client hints and the other headers a browser sends, which are listed on the HTTP headers page.

Request a desktop or mobile site. Most mobile browsers have a request-desktop-site option that switches the user agent for that tab. This is the one legitimate everyday reason to change it, and the switch is visible here.

Limits of this check

• Parsing is pattern matching. The parser recognizes the major browsers, engines and systems and a list of common crawlers and tools. An unusual browser, a webview inside an app or a new crawler may be labeled by its underlying engine or left as unknown.
• The string is self-declared. Anything can send any user agent. This page reports what was sent; it does not verify it. Cross-checks against client hints and the fingerprint signals are how you tell an honest string from a rewritten one.
• Modern user agents are reduced on purpose. Chromium browsers freeze the platform version and report a reduced browser version; the detail moved to client hints that are only sent when a site asks for some of them, so the hints row may not show everything your browser could reveal.
• Firefox and Safari do not send client hints, so for those browsers the hints row stays empty and the user agent is the only source.
• iPadOS hides itself. Safari on iPad sends the macOS string by default, and the parser reports what it sends.
• Bot detection uses a list. Crawlers that identify themselves honestly are recognized; a script that copies a browser string is not caught by this field, though it may be caught by the automation checks in the anonymity score.

Why the user agent string looks the way it does

The string is a history lesson. Early browsers identified themselves as Mozilla, and sites served better pages to Mozilla, so every later browser claimed to be Mozilla too. Then sites keyed on Gecko, and WebKit browsers added "like Gecko". Then sites keyed on Safari, so Chrome added Safari, and then Edge added Chrome. The result is a string where almost every token is there for compatibility and only the last one or two name the real product, which is why the parser reads it from the most specific token backwards. The user agent glossary entry walks through a full string token by token.

Client hints: where the detail went

Because the user agent string became a fingerprinting surface, Chromium browsers reduced it and moved the detail into client hint headers. A few are sent with every request: the browser brands and major version, whether the device is mobile, and the platform name. The rest, such as the full version, the platform version, the CPU architecture and the device model, are sent only after a site asks for them in a response header. The hints row on this page shows the ones your browser sent to us. For a site that wants to know whether you really run the platform your user agent claims, the hints are the first thing it checks, which is why rewriting the user agent without the hints is worse than leaving both alone. The client hints entry lists each header and what it carries.

Does the user agent reveal who I am?

On its own, no. A current browser version on a common platform is shared by an enormous number of people, and the string carries nothing about you personally. It matters in two other ways. Combined with screen size, fonts, graphics card and the rest, it contributes to a fingerprint that can recognize your browser across sites; that is the subject of the browser fingerprint page. And compared with the other evidence in a session, it is a consistency check: a user agent that contradicts the client hints, the device or the IP's expected platform draws attention, while an ordinary, current, honest one does not.