VoriTools

View Your User-Agent

View the User-Agent received by the server and compare it with desktop, mobile and crawler examples. These strings can be reduced or changed, so they are not reliable proof of a device’s identity.

View category: Reference & Lookups (21)
Representative User-Agent strings

User-Agent strings change over time and may be reduced for privacy. Use feature detection for application behavior; use these values only for testing parsers and logs.

ClientUser-Agent example
Chrome · Windows
Edge · Windows
Safari · macOS
Firefox · Linux
Chrome · Android
Safari · iPhone
Firefox · Android
Googlebot

How to read a User-Agent string

The block at the top of this page prints the User-Agent header the server received for this request, character for character: a value that contains angle brackets arrives escaped, and a client that sends no header leaves the block empty.

The table below it is a fixed list of eight known strings — Chrome and Edge on Windows, Safari on macOS and iPhone, Firefox on Linux and Android, Chrome on Android, and Googlebot — kept for parser and log work. The version numbers in them are samples from the end of 2024, not the latest releases.

  1. Read the string your client sent in the top block, or copy one of the eight examples when you need a known good value.
  2. Filter the table with the field above it: the query is matched against the client name and against the full string, without regard to case, so android leaves two rows and EDG/ leaves the Edge row.
  3. Press the copy button in a row to put that row's string on the clipboard; the read-only field itself can also be selected and copied by hand.
  4. Use Clear or the Escape key to bring all eight rows back; the counter beside the field shows how many of the eight are visible.
  5. Treat a User-Agent as a hint rather than an identity: browsers reduce it and a program can replace it entirely.

What the eight examples are

What the page shows and what it does not

Shown: the header of this request and eight reference strings. Not shown: any parsing of that header into browser, engine, operating system, device model or bot name. The page never decides which browser you are using; it repeats what the request carried and puts it next to examples.

Searching, copying and scrolling send nothing anywhere: the filter runs inside the page, and the page's own network traffic stays limited to its scripts and stylesheets.

Where the eight strings come from

Each string follows the format its vendor documents: Chrome and Edge carry AppleWebKit/537.36, Chrome/131.0.0.0 and Safari/537.36, Edge adds Edg/131.0.0.0, Firefox reports rv:133.0 with Gecko/20100101 and Firefox/133.0, and Safari identifies itself through Version/18.1 and Safari/605.1.15.

The mobile rows mix in platform tokens (Android 14, Pixel 8, CPU iPhone OS 18_1, Mobile/15E148), and the crawler row is Googlebot's classic desktop string with its +http://www.google.com/bot.html URL. Because the numbers are frozen, a current browser reports a higher version than the row that carries its name.

Using a string in tests and log rules

A fixed sample is useful precisely because it does not change: paste it into a log parser, a bot filter or a unit test and it keeps a stable expected value, while the live string at the top of the page changes with every browser update.

Do not branch application behaviour on the User-Agent. Feature detection answers what the browser can do; the header answers only what the client chose to claim that day, and a claim can be reduced, frozen or invented.

Recent tools: