What Is a User Agent?

The expression comes from the HTTP specifications. RFC 1945, from May 1996, defines the user agent as "the client which initiates a request" and lists browsers, editors, spiders (web-traversing robots) and other end-user tools. RFC 9110 adds that browsers are only a small share: mobile apps, household appliances and firmware update scripts are user agents too.

Almost every browser starts its string with "Mozilla/5.0". MDN puts this down to "historical reasons". The HTML Standard keeps the same legacy in JavaScript: navigator.appCodeName always returns "Mozilla" and navigator.appName returns "Netscape", so that existing websites keep working. Engine names went the same way. According to MDN, many browsers added the names of other engines so that websites would not shut them out by name. That is why Chrome writes "KHTML, like Gecko" and "Safari" although it is neither. RFC 9110 discourages the practice because it defeats the purpose of the field.

• May 1996: RFC 1945 (HTTP/1.0) introduces the User-Agent header. Clients should send it, but it is not required.
• June 1999: RFC 2616 (HTTP/1.1) keeps it in section 14.43, with the same example "CERN-LineMode/2.15 libwww/2.17b3".
• June 2014: RFC 7231 adds a warning: long, detailed strings raise the risk of a person being identified against their wishes, known as fingerprinting.
• June 2022: RFC 9110 replaces RFC 7231 and is the current standard. A user agent should send the header with every request.
• 13 June 2022: Chrome 101 reaches 100 % of users with the minor version numbers frozen at 0.0.0, according to the Chromium schedule.
• 7 February 2023: Chrome 107 completes the reduced string on desktop.
• 11 May 2023: Chrome 110 completes the reduced string on Android.
• 26 October 2026: latest version of the User-Agent Client Hints draft from the WICG community group, which is not a W3C standard.

The browser sends the User-Agent header with every HTTP request. Under RFC 9110, the value consists of one or more products, each with a name and an optional version (product/version), followed by comments in parentheses. Products are listed in decreasing order of importance for identifying the software. The standard forbids putting advertising into the product name.

Chrome's string on Windows, read on 15.11.2026 in our own browser, breaks down like this:

Source: navigator.userAgent in Chrome 157 (15.11.2026); MDN, "User-Agent header"; Chromium, "User-Agent Reduction".

RFC 9110 names three uses of the string: narrowing down compatibility problems, tailoring the response to a client and producing statistics on browsers and operating systems. If the response changes with the user agent, the server should say so with the Vary header. RFC 9110 requires caches not to reuse a response for another request unless the headers listed in Vary match. Without "Vary: User-Agent", a cache or a CDN can hand the mobile version to a desktop computer or the other way round. Google calls this setup, the same URL with different HTML per device, "dynamic serving" and bases it on reading the user agent and on "Vary: user-agent".

Today the user agent arrives in two forms: the classic string, which Chrome has trimmed, and User-Agent Client Hints, separate headers that deliver the same data piece by piece.

The reason is privacy. The WICG draft presents Client Hints as a way to adapt content without the passive fingerprinting surface of the User-Agent header. Chrome froze the most detailed parts of the string in three phases: first the minor version numbers (Chrome 101), then the desktop string (Chrome 107) and finally the Android string (Chrome 110). According to Chromium, the platform becomes a literal value: on Android, "Linux; Android 10; K", even if the system or the phone is different.

Source: WICG, "User-Agent Client Hints", 26.10.2026; Chrome for Developers, "User-Agent Client Hints".

The first three are low entropy and sent by default. For the rest, the server responds with Accept-CH and the browser adds them to the following requests. Chrome only sends Client Hints over HTTPS. In JavaScript they are read with navigator.userAgentData and getHighEntropyValues(). The brand list of our Chrome 157 contains a fictitious one, "Not-A.Brand": the WICG draft proposes such fake entries (GREASE) so that websites do not look for an exact name.

Chrome has turned Client Hints on by default since version 89. According to MDN's compatibility data (15.11.2026), Firefox and Safari do not support navigator.userAgentData, and MDN marks the API as experimental.

Safari on iPhone, according to MDN: "Mozilla/5.0 (iPhone; CPU iPhone OS 18_6 like Mac OS X) AppleWebKit/605.1.15 (KHTML, like Gecko) Version/26.0 Mobile/15E148 Safari/604.1". According to MDN, Safari gives its version with "Version/", here 26.0, and adds "Mobile" on iPhone. MDN also notes that Firefox, Chrome and Edge on iPhone run on WebKit too, so their strings look like Safari's.

Firefox on macOS, according to MDN: "Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:138.0) Gecko/20100101 Firefox/138.0". "rv:138.0" is the version of the Gecko engine and "20100101" is a fixed value on desktop.

curl, the command-line tool: according to its manual it sends "curl/VERSION" by default, for example "curl/8.23.1". That is a user agent with no browser behind it.

Googlebot Smartphone, according to Google's documentation updated on 30.10.2026: "Mozilla/5.0 (Linux; Android 6.0.1; Nexus 5X Build/MMB29P) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/W.X.Y.Z Mobile Safari/537.36 (compatible; Googlebot/2.1; +http://www.google.com/bot.html)". W.X.Y.Z is a placeholder that Google fills with the Chrome version it uses at the time.

In server logs, the user agent is recorded on every line. Apache's "combined" format stores it with %{User-agent}i and nginx's with $http_user_agent, so an ordinary log line already says which program requested each URL. Log file analysis starts there to separate visits by people from visits by crawlers. For Googlebot, Google advises filtering with wildcards in the Chrome version, because that number changes over time.

Advantages: it arrives with every request without JavaScript, and any server can log it. It works for statistics by browser or operating system and for narrowing down bugs in one version.

Disadvantages: the client writes it, so it proves nothing. In Chrome it no longer gives the exact version or the phone model. Its format is not uniform, MDN warns, and some browsers give conflicting information: Chrome declares itself both Chrome and Safari.

Crawlers also introduce themselves with a user agent, but robots.txt does not work with that string. Under RFC 9309, each crawler has a short token that should appear within its string, and robots.txt rules are written with that token: "Googlebot", not the whole string above. Because the string can be copied, the name does not prove who is calling: how to verify a real visit is explained under Googlebot, and the strings of GPTBot, ClaudeBot or PerplexityBot under AI crawlers.

Source: RFC 9110; RFC 9309; WICG, "User-Agent Client Hints"; Google, "Verify requests from Google crawlers and fetchers".

Open-source libraries exist for breaking strings down. In alphabetical order:

• Device Detector (Matomo): according to its repository, detects browser, operating system, device type, brand and model; licence LGPL-3.0.
• UAParser.js: a JavaScript library for the browser and Node that, according to its repository, detects browsers, operating systems, devices and bots; licence AGPL-3.0.
• uap-core: the regular expression file of the Browserscope parser, the basis for ports in several languages.

RFC 7231 already warned in 2014 that a long string helps identify a person against their wishes (fingerprinting). The Client Hints draft gives the same reason.

Deciding from the string which features to use also fails. In MDN's example, a script that assumes every "Chrome" supports a feature breaks with older versions and with browsers that add it later. MDN adds that the problem is the same with Client Hints and recommends checking for the feature directly (feature detection).

Finally, the string can be faked. Google warns that other crawlers often copy Googlebot's user agent.

• See your own user agent: open the browser's developer tools, Network tab, and look at the User-Agent header of any request, or type navigator.userAgent in the console.
• See the Client Hints: the same request shows Sec-CH-UA and the others; in the console, navigator.userAgentData.
• Change it in Chrome: developer tools, Network conditions panel, untick "Use browser default" under User agent and pick or type another one. According to Google, this changes what the website sends you, not how Chrome works.
• Change it in curl: curl -A "text". With -A "" curl sends no header at all.
• Draw the conclusion: if changing it takes one click, the string is no proof of identity.

• Check features with feature detection, not with the browser name.
• If the response depends on the device or browser, send "Vary: User-Agent".
• Request only the Client Hints you will use with Accept-CH.
• Identify bots by IP and reverse DNS, not by the name they declare.
• In logs, filter by string and by IP together.

• Blocking or letting a crawler through based on its user agent alone.
• Serving different HTML per device without the Vary header.
• Looking for Chrome's full version in the string: since Chrome 101 it ends in 0.0.0.
• Filtering logs by an exact Googlebot version instead of using wildcards.
• Detecting Gecko by searching for "Gecko" and counting Chrome and Safari, which carry "like Gecko", as Firefox.

We wrote this entry in November 2026 with the help of AI. The information comes from the IETF RFC standards, the HTML Standard, the User-Agent Client Hints draft, MDN, documentation from Chrome, Chromium and Google, the curl, Apache and nginx manuals and the repositories cited. We reviewed it before publishing and it contains no client data.