Frozen user agents: what device reports can still prove

Three details the user agent no longer reveals

For a long time, the user agent was a string from which analytics read browser, version, operating system and often even the device model. User-Agent reduction removes three pieces of information from it: the exact platform or operating system version, the device model and the minor browser version (MDN Web Docs). They are not replaced by gaps but by fixed values. Platform version and device model are represented by constants (MDN Web Docs), and that is exactly the problem for reports: a constant looks like a measurement. It has the right format, it can be counted, sorted and charted. It just says nothing about the device that triggered the page view.

Chromium applies the reduction to Windows, macOS, Linux, Chrome OS and Chrome on Android (Chromium). The project documentation states explicitly that these are literal values which do not update even if a user is on an updated operating system or device (Chromium). A current flagship phone, a tablet from another manufacturer and an older entry-level device therefore send the same platform token. The following overview compares what the reduced user agent contains, what a report typically makes of it and what is actually supported by evidence.

The values in the table come from the MDN documentation on User-Agent reduction, which lists Android 10; K for Android, Macintosh; Intel Mac OS X 10_15_7 for macOS and Windows NT 10.0; Win64; x64 for Windows as fixed values (MDN Web Docs). The minor version appears as 0.0.0 in every case; only the major version is shown correctly (MDN Web Docs). The example from the same source shows the difference on a single device:

# before reduction (example from MDN Web Docs)
Mozilla/5.0 (Linux; Android 16; Pixel 9) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/143.0.12.45 Mobile Safari/537.36

# after reduction
Mozilla/5.0 (Linux; Android 10; K) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/143.0.0.0 Mobile Safari/537.36

Before the reduction, the string contained Android 16 with the model Pixel 9 and the full version number 143.0.12.45; afterwards it reads Android 10, model K and 143.0.0.0 (MDN Web Docs). Browser family and major version survived the reduction, everything else is a placeholder. A report that evaluates the second line therefore does not count Android 10 devices but Chrome page views from Android devices of any version. Model K is not a device anyone should add to a test matrix.

The stages of the reduction: from Chrome 101 to Chrome 113

The reduction did not arrive on a single date but in stages. The Chromium project page describes them as phases; four of them matter for reports (Chromium). Anyone looking at a time series across these versions will see breaks that no change in user behaviour explains. The line looks continuous, but its foundation has shifted underneath it.

1. Chrome 101: the MINOR.BUILD.PATCH version numbers are reduced and shipped as 0.0.0 (Chromium).
2. Chrome 107: roll-out of the reduced desktop user agent begins, including navigator.userAgent, navigator.appVersion and navigator.platform (Chromium).
3. Chrome 110: roll-out begins on Android, for phones and tablets (Chromium).
4. Chrome 113: the reverse origin trial ends and all page loads receive the reduced user agent and the related JavaScript APIs (Chromium).

macOS is a special case: the platform version was already capped to 10_15_7 in Chrome 90 for site compatibility reasons (Chromium). The motive was compatibility rather than privacy, but the effect on reports is the same. An analysis that sorts macOS versions from Chrome page views has therefore shown a single value since Chrome 90, long before the other platforms followed.

Not every browser on every platform is affected. According to Chromium, there are currently no plans for User-Agent reduction on iOS and Android WebView (Chromium). Page views from browsers embedded in apps can therefore still carry more detailed information than page views from the Chrome browser itself. A report then mixes genuine version details from WebViews with frozen ones from Chrome. A share with a current Android version may come from a single app, while the constant Android 10 stands for all remaining Chrome page views.

Anyone who compares year-over-year figures across shifting sale days knows such breaks: the curve continues although the basis of measurement has changed. With device data it is the browser that shifts the basis, not the calendar. If you compare operating system versions over several years, mark the Chrome version jumps in the chart and read the periods before and after them separately.

The iPad that pretends to be a Mac

Independently of Chromium, Apple changed the iPad user agent earlier. With Safari 13, Safari on iPad, with the exception of iPad mini, sends a user agent string that is identical to Safari on macOS (WebKit). The goal behind the change was to deliver the desktop version of websites on a touch device (WebKit). The WebKit blog describes that, most of the time, Safari on iPad presents a macOS user agent when loading a page (WebKit). For reports this means that a considerable part of iPad traffic appears under macOS and therefore usually under desktop.

There is an exception to the exception: if a page is loaded or reloaded while Safari is reduced to a one-third width in multitasking, Safari sends an iOS user agent because the mobile layout fits better there (WebKit). The same device can thus appear in a report as a Mac and as an iPad on the same day. Anyone comparing device shares over time will see fluctuations that relate to window arrangement rather than to the audience.

The practical consequences: the tablet share is underestimated, the Mac share overestimated, and touch testing gets too little weight. This can matter for offerings that are often used on a tablet, such as catalogues, recipe pages or booking flows. WebKit itself advises developers to test their desktop website experience on an iPad (WebKit). The field data blind spot on iOS Safari amplifies the effect: where loading data comes only from Chrome, the iPad share is missing there too.

Windows 10 or 11: a question the user agent cannot answer

On Windows the situation is even clearer. Microsoft writes that user agent strings won't be updated to differentiate between Windows 11 and Windows 10, or between CPU architectures (Microsoft Learn). The platform token Windows NT 10.0; Win64; x64 therefore appears on Windows 10 and on Windows 11 alike, regardless of processor architecture. Browsers that don't support User-Agent Client Hints cannot tell the two versions apart at all (Microsoft Learn). According to Microsoft's overview this applies to Firefox, while Edge, Chrome and Opera support the distinction via client hints (Microsoft Learn).

A report that shows “Windows 10” is in fact adding Windows 10 and Windows 11 together. Anyone who concludes from this that there is a large share of outdated systems, and plans testing effort for older Windows versions or aligns an upgrade campaign with that share, is working with a sum that cannot be broken down. The honest label is “Windows 10/11”. The distinction is only possible via a high-entropy hint that the server must request explicitly: web servers must send the Accept-CH response header to request higher entropy fields not sent in the Sec-CH-UA header by default (Microsoft Learn).

What still holds in a device report

Less remains after the reduction, but what remains is more reliable than before. The default set of client hints includes the browser name with major version, the platform and the mobile indicator (Chromium). MDN lists Save-Data, Sec-CH-UA, Sec-CH-UA-Mobile and Sec-CH-UA-Platform as low-entropy hints (MDN Web Docs). Low-entropy hints are those that give away little information that could be used to fingerprint a user (MDN Web Docs). Unless a permission policy blocks it, Sec-CH-UA is sent by default, without the server opting in via Accept-CH (MDN Web Docs). Together with viewport and screen class, this gives six details a device report can rely on:

These details deserve a second look as well. Sec-CH-UA may include fake brands in any position and with any name (MDN Web Docs). That is intentional: analyses should not depend on exact brand lists that exclude every new browser. And the version in the header is the significant version: a Chromium build with the full version number 96.0.4664.45 reports 96 there (MDN Web Docs). An analysis must therefore filter out placeholder brands and must not expect patch levels from the header.

The screen class adds what the user agent no longer says. It answers the question behind most device questions: what does the page look like on the screens the audience actually uses? To check this, open the page in the responsive preview across several widths instead of optimising for device models that only appear as a constant in the report anyway.

High-entropy hints: only on explicit request

The information has not disappeared. Everything the user agent contained before the reduction is available through the high-entropy client hints, on request via the User-Agent Client Hints request headers or via the JavaScript API navigator.userAgentData.getHighEntropyValues (Chromium). High-entropy hints are those that can give away more information for fingerprinting, and they are therefore gated so that the browser can decide whether to provide them (MDN Web Docs). All client hints that are not low-entropy hints are considered high-entropy hints (MDN Web Docs). This is what such a request looks like:

# response header: the server requests details
Accept-CH: Sec-CH-UA-Platform-Version, Sec-CH-UA-Model, Sec-CH-UA-Full-Version-List

# JavaScript: asking the device
navigator.userAgentData.getHighEntropyValues(['platformVersion', 'model', 'fullVersionList'])

The mechanism behind it is described in RFC 8942. The document defines the Accept-CH response header, which allows an origin server to explicitly ask the browser to send these headers in requests (RFC 8942). Because client hints are an explicit opt-in mechanism, servers that want information about the user's environment need to actively ask for it; browsers and privacy researchers can thus track which origins collect that data and act upon it (RFC 8942). If the browser agrees, it sends the requested headers in all subsequent requests until the browser or tab is closed (MDN Web Docs).

The HTTP header checker shows whether your own website already sets Accept-CH. This can happen without the operator being aware of it, for example because a plugin, an upstream cache or an embedded script configured the header. If you want to run measurement without consent, you should know which details your own website requests from the device.

Why cookieless measurement deliberately does without them

RFC 8942 names the reason the reduction happened in the first place: user agent detection cannot reliably identify all static variables, requires an external device database, is not cache friendly and relies on a passive fingerprinting surface (RFC 8942). Under the heading of entropy, the document notes that highly granular data can be used to help identify users across multiple requests to different origins (RFC 8942). That is precisely the data high-entropy hints deliver: exact operating system version, device model, full version numbers.

For measurement without consent, this is first a legal question. Under § 25(1) TDDDG, the German Telecommunications Digital Services Data Protection Act, storing information in the end user's terminal equipment or accessing information already stored there is only permitted if the end user has consented on the basis of clear and comprehensive information (TDDDG). Whether actively requesting high-entropy values counts as such access has not been conclusively settled and depends on the individual case; this article is not legal advice. If you want to run measurement without a consent banner, however, you are well advised not to raise the question at all.

The technical side is just as clear. A measurement that deliberately avoids cookies and recognition would undermine its own concept if it collected, at the same time, the characteristics best suited to recognising people. The trade-off has a price: no separate figures for Windows 11 and Windows 10, no device models, no patch levels. The gain is a report that claims nothing it has not measured. The article on cookieless tracking without consent banners explains in more detail why the principle holds; the page on GDPR compliance at XICTRAQ covers the data protection side of the measurement.

Checking your own device report

Whether a report presents constants as measurements can be established in a few steps. The following steps work with any tool that offers breakdowns by operating system version, device model or browser version, and just as well with your own server's access logs.

1. Break down Android versions by browser: if a single value, Android 10, dominates Chrome page views, that is the constant Android 10; K and not a device generation (MDN Web Docs).
2. Look at device models: if model K appears, it comes from the reduced user agent. It belongs neither in a test matrix nor in an audience description.
3. Look at macOS versions: a cluster at 10.15.7 shows the capped value, not the software level of Mac users (Chromium).
4. Look at the Windows label: if it says “Windows 10”, it really means the sum of Windows 10 and Windows 11 (Microsoft Learn).
5. Look at minor versions: if browser versions end in .0.0.0, only the major version is reliable (MDN Web Docs).
6. Compare the iPad share with screen classes: a conspicuously small tablet share alongside many Mac page views with tablet resolutions points to iPads behind the Mac user agent (WebKit).
7. Read time series at the version jumps: breaks around Chrome 101, 107, 110 and 113 are more likely consequences of the reduction than changes in behaviour (Chromium).

If you have access logs from your own server, you can search for the constants directly. The following example shows three queries and the values they match; the output is shortened to the first hit.

Every line that matches one of these patterns carries no device information at that position. Relating the hits to all page views of the respective platform shows how large the share of constants in your own report is, and therefore how little the version column still says. Automated requests distort the picture further, because many crawlers send outdated or invented identifiers; the article on filtering bot traffic in web analytics describes how to separate them.

How XICTRAQ Analytics handles frozen values

XICTRAQ Analytics is built for exactly this situation. Of the client hints, XICTRAQ evaluates only the three low-entropy hints Sec-CH-UA, Sec-CH-UA-Mobile and Sec-CH-UA-Platform, which the browser sends with the measurement request by default anyway. The website sends no Accept-CH for this, and the tracker does not call getHighEntropyValues. Besides the user agent, the device class relies on the mobile flag, the viewport width and the screen size. The documentation on analytics reports describes how these values appear in the reports.

• Android 10; K: is listed as Android without a version, because the version is a constant.
• macOS 10.15.7: is listed as macOS without a version, for the same reason.
• Windows NT 10.0: appears as Windows 10/11, because the user agent does not separate the two versions.
• iPad behind the Mac user agent: is recognised as a tablet via screen resolution and portrait orientation instead of being counted as a Mac.
• Screens: can be analysed via ready-made classes such as Full HD, WQHD, UHD/4K and ultrawide instead of comparing individual pixel values.

The tracker settings list which signals the tracker records; the guide to the JavaScript tracker describes the technical integration. In the report, device, browser and operating system can be broken down and filtered by resolution or screen class. Frozen version fields stay empty instead of being filled with a constant.

Which decisions device reports can still support

For browser support, browser family and major version remain reliable. If you want to decide from which version a feature ships without a fallback, the report still contains that information. For layout and testing, mobile flag, viewport and screen class hold; device models do not. For operating system questions, the platform holds, the version usually does not.

Statements about old Android devices, about the share of Windows 10 and about the spread of particular Mac software levels are no longer reliable, insofar as they come from Chrome page views. Anyone who has to answer such questions needs a different data source with consent, such as a voluntary survey or support data with permission, not web analytics. The same applies to AI browsers, whose page views can likewise only be classified via client hints and behaviour; the article on AI browsers in web analytics shows how Sec-CH-UA contributes to telling them apart.

For planning, this means: allocate test budgets by screen class and browser family, not by device model. Tie support commitments to major versions, not to patch levels. And mark every metric based on an operating system version with a note on whether it stems from a constant. The XICTRAQ pricing overview shows which plan includes which depth of analysis.