Open the Network panel in your browser's developer tools and you will almost always find a User-Agent header. It looks like a short introduction: which browser is making the request, which operating system it runs on, and which version it claims to be.
That makes it tempting to treat the header as a device ID—or to assume that changing one line can turn a browser into a different device. Both ideas are only partly correct.
A User-Agent string, or UA, is compatibility information declared by the client. It is not a trusted identity credential, and a client can modify it. Yet it does not exist in isolation. A site can compare the UA with Client Hints, JavaScript APIs, screen properties, fonts, Canvas, WebGL, network context, and behavior. The useful question is therefore not simply whether a UA can be changed, but what role it plays in the browser's complete observable surface.
This article uses HTTP standards and browser-fingerprinting research to answer four questions:
- Why does a UA string look like a piece of browser archaeology?
- How much identifying information can UA contribute, and how should we interpret the research?
- Why can changing only the UA create a more obvious inconsistency?
- What did UA Reduction and User-Agent Client Hints actually change?
In this article, UA primarily means the HTTP
User-Agentrequest header. We also discussnavigator.userAgentandnavigator.userAgentDatain JavaScript. These interfaces are related but not permanently identical across every browser and context.
1. What is a User-Agent?
Section 10.1.5 of RFC 9110 defines User-Agent as a field containing information about the user agent that originated the request. Its simplified grammar is:
User-Agent = product *( RWS ( product / comment ) )
product = token [ "/" product-version ]
In plain language, the string starts with a product name and may include a version. More products or comments can follow. The standard recognizes uses such as interoperability workarounds, diagnostics, and analytics, but it also advises implementations not to reveal unnecessary detail: a longer, more specific UA increases both request size and fingerprinting risk.
A modern Chromium desktop UA might look like this:
Mozilla/5.0 (Windows NT 10.0; Win64; x64)
AppleWebKit/537.36 (KHTML, like Gecko)
Chrome/145.0.0.0 Safari/537.36
Splitting the string by spaces reveals several names that appear unrelated to Chrome:
| Token | What it generally means today | A common misreading |
|---|---|---|
Mozilla/5.0 | A historical compatibility token | The browser must be Firefox or a Mozilla product |
Windows NT 10.0 | A Windows platform category; a reduced UA cannot reliably distinguish Windows 10 from 11 | The computer must run Windows 10 |
Win64; x64 | A clue that this is 64-bit Windows on an x86-64 architecture | It proves the exact physical CPU model |
AppleWebKit/537.36 | An engine-lineage and compatibility token | Chrome still uses Safari's complete implementation |
KHTML, like Gecko | Historical compatibility language | Both KHTML and Gecko are running |
Chrome/145.0.0.0 | The Chrome/Chromium family and major version; lower version components may be reduced | It reveals the precise patch version |
Safari/537.36 | A token retained for compatibility with older sites | The browser must be Safari |
The UA became verbose because early websites often branched on browser names. New browsers had to claim compatibility with older products to receive the correct page. These declarations accumulated over time, creating a historical record that cannot be read literally.
The first rule of UA parsing is therefore simple: it is a compatibility protocol, not a strict device description.
2. Why do websites still use UA?
UA is not used only for tracking. Legitimate uses include:
- serving a fallback to an older browser with a known compatibility problem;
- selecting an appropriate installer or download format;
- finding version-specific failures in diagnostic logs;
- measuring broad browser-family, platform, and major-version distributions;
- identifying impossible combinations in automated or malicious traffic.
The problem begins when UA sniffing moves from a narrow compatibility fallback to guessing capabilities by product name. Code may see Chrome and assume that a particular API exists. That assumption can fail in an embedded WebView, a Chromium-derived browser, a browser with an enterprise policy, a frozen UA, or a client that changed its header.
A more robust order of operations is:
- Test the required API or behavior directly whenever capability detection is possible.
- When browser identification is unavoidable, use a maintained parser rather than an ad hoc regular expression.
- Store only the coarse categories the product genuinely needs.
- Provide a fallback for unknown brands, unknown versions, and missing fields.
3. Is UA a browser fingerprint?
More precisely, UA is one input to a browser fingerprint, not usually the complete fingerprint.
Browser fingerprinting does not require a secret serial number. It measures a collection of relatively stable, distinguishing attributes exposed by the browser. UA contributes clues about browser family, version, and platform. Screen dimensions, fonts, timezone, Canvas, WebGL, AudioContext, and other interfaces add further information.
The survey by Laperdrix and colleagues, Browser Fingerprinting: A Survey, discusses these techniques as a form of stateless recognition. A site does not necessarily have to write a Cookie first; it can attempt to associate visits from the attributes a browser exposes. “Stateless” does not mean that the server stores nothing. It means that the recognition material does not depend on a persistent client-side identifier.
1. What does the paper's 10-bit result mean?
In the 2010 Panopticlick study How Unique Is Your Web Browser?, Peter Eckersley analyzed roughly 470,000 browser fingerprints. The paper reported that:
- the complete fingerprint carried an average of about 18.1 bits of identifying information in that sample;
- put intuitively, an average fingerprint occurred roughly once in 286,777 browsers;
- the table reported about 10.0 bits of average information for the UA string alone;
- among browsers with Flash or Java enabled, 94.2% of complete fingerprints were unique.
Self-information is commonly written as:
I(x) = -log₂ P(x)
If a particular UA occurs with probability 1/1024 in a population, observing it provides 10 bits of information. This does not mean that UA has exactly 1,024 possible values or that it uniquely identifies a person. It describes how much uncertainty that observation removes on average.
2. Why is the 2010 result not a constant for today's web?
The result remains important, but it needs at least three qualifications:
- visitors to a privacy-testing page were not a random sample of all internet users;
- browser, plugin, and UA-version diversity in 2010 differed greatly from today's ecosystem;
- UA Reduction, shrinking plugin surfaces, and anti-fingerprinting protections have changed the distribution of observable attributes.
The study supports the claim that UA and other attributes can contribute measurable distinguishing information. It does not support saying that a UA always has exactly 10 bits of entropy today. Fingerprinting power depends on the population, time window, browser policies, and the combination of signals.
4. Why can changing only UA backfire?
UA is a client declaration without cryptographic proof. A server cannot read a device's factory truth from this header. It can, however, check whether different observations are reasonably compatible.
Suppose a UA claims to be a mobile browser, but the page observes no touch points, a window that consistently resembles a desktop display, and Client Hints that report a desktop platform. Any one observation may have a legitimate exception. Several stable contradictions together can still form a classifiable pattern.
The Panopticlick paper already documented comparable cases: some browsers claimed to be an iPhone while supporting Flash, and some Firefox UAs appeared alongside storage features available only in Internet Explorer. The 2018 FP-Scanner study examined this problem systematically. Some anti-fingerprinting extensions and spoofing tools introduced inconsistencies across interfaces, allowing a detector to identify modified attributes and, in some cases, infer the original browser or operating-system family.
Not every inconsistency is malicious. Remote desktops, accessibility tools, enterprise policies, compatibility layers, and uncommon hardware can all create unusual combinations. A careful risk system should treat an inconsistency as probabilistic evidence, not an automatic reason to block a user.
For browser-profile management, three properties matter:
- Internal consistency: UA, Client Hints, platform, architecture, touch, and screen signals should not directly contradict one another.
- Stability over time: a long-lived profile should not change dramatically at every launch without a reason.
- Plausible diversity: profiles may differ, but rare mechanically generated combinations are not necessarily safer.
The FP-STALKER study also showed that changing attributes do not automatically prevent linkage. A model can use stable attributes and plausible version changes to connect earlier and later fingerprints.
5. What problem does UA Reduction address?
A traditional UA is sent with nearly every request. Any first-party or third-party endpoint that receives the request can read it passively. The more precise the string, the more distinguishing information every recipient obtains by default.
Chromium's User-Agent Reduction plan reduces this default granularity:
- beginning with Chrome 101, desktop minor, build, and patch versions were reduced to
0.0.0; - later phases unified desktop operating-system versions, CPU details, and Android device information;
- a reduced Android UA uses fixed platform and model values such as
Android 10; K; - sites that genuinely require more detail can request User-Agent Client Hints.
The reduced format can be summarized as:
Mozilla/5.0 (<unified platform information>)
AppleWebKit/537.36 (KHTML, like Gecko)
Chrome/<major version>.0.0.0 Safari/537.36
Reduction decreases the passive fingerprinting surface of the legacy UA. It does not eliminate browser fingerprinting. The major version, broad platform, and mobile state may remain visible, while other APIs, network properties, and behavior can still provide information.
6. How do User-Agent Client Hints work?
The general mechanism is defined in RFC 8942, while the WICG User-Agent Client Hints draft describes UA-specific fields. The approach splits information that once lived in an unstructured string into structured fields, distinguishing low-entropy hints that may be sent by default from high-entropy hints that a site normally requests explicitly.
A simplified initial request may look like this:
GET /download HTTP/1.1
User-Agent: Mozilla/5.0 (...) Chrome/145.0.0.0 Safari/537.36
Sec-CH-UA: "Chromium";v="145", "Not_A Brand";v="99"
Sec-CH-UA-Mobile: ?0
Sec-CH-UA-Platform: "Windows"
If the server genuinely needs architecture and bitness to select an installer, it can respond with:
HTTP/1.1 200 OK
Accept-CH: Sec-CH-UA-Arch, Sec-CH-UA-Bitness
Vary: Sec-CH-UA-Arch, Sec-CH-UA-Bitness
When the browser supports the mechanism and the security and policy requirements are met, a later request can include:
Sec-CH-UA-Arch: "x86"
Sec-CH-UA-Bitness: "64"
Common UA Client Hints include:
| Field | Typical purpose | Information level |
|---|---|---|
Sec-CH-UA | Brand and major-version list | Usually low entropy |
Sec-CH-UA-Mobile | Whether the client prefers a mobile experience | Usually low entropy |
Sec-CH-UA-Platform | Broad platform category | Usually low entropy |
Sec-CH-UA-Arch | CPU architecture | High entropy; request when needed |
Sec-CH-UA-Bitness | Architecture bitness | High entropy; request when needed |
Sec-CH-UA-Platform-Version | Platform version | High entropy; request when needed |
Sec-CH-UA-Full-Version-List | Full versions for reported brands | High entropy; request when needed |
Sec-CH-UA-Model | Device model | High entropy; request when needed |
Three engineering details are easy to miss.
1. Client Hints are not all sent automatically
Low-entropy hints may appear by default. High-entropy hints usually require an Accept-CH response. Initial navigation, subresources, permissions policy, secure transport, and browser support can all affect what arrives. A server must allow every optional field to be absent.
2. The brand list deliberately tests parser robustness
Sec-CH-UA can contain multiple brands and a synthetic brand used to test compatibility. Code must not assume that the first entry is always the product name, and it must not fail when an unknown brand appears. Parse the structured field, ignore entries you do not recognize, and leave room for future brands.
3. Responses that vary on hints need correct cache handling
If architecture, platform, or another hint changes the response, configure Vary or an equivalent cache-key strategy correctly. Otherwise, a shared cache may serve content generated for one device class to another.
7. Are Client Hints more private than the traditional UA?
They improve how information is exposed, but they do not provide immunity from fingerprinting.
The traditional UA reveals a large unstructured bundle passively and by default. Client Hints split that bundle into fields, make requests for higher-entropy information more explicit, and give the browser an opportunity to apply policy, permission, or privacy-budget controls.
However, architecture, full versions, platform versions, and device models can still increase distinguishability. RFC 8942 explicitly treats privacy and performance as design constraints. Developers should ask:
- Does this feature genuinely require the field?
- Can capability detection or a user choice replace it?
- Can the application store only a coarse category?
- How long are raw values retained, and who can access them?
- Will third-party resources receive the same hints?
8. Engineering guidance for server-side UA handling
1. Never use UA as proof of identity or authority
UA can support presentation choices and compatibility fallbacks. It should not determine identity, authorization, payment trust, or a security boundary. A client-controlled value cannot serve as an access-control credential.
2. Prefer capability detection to browser lists
When a front end needs an API, test for that capability directly:
if ('share' in navigator) {
// Offer the system share feature.
} else {
// Fall back to copying a link.
}
Capability detection handles derived browsers, experimental features, enterprise policies, and future releases better than a rule such as “enable this for Chrome 145.”
3. Accept legacy UA, Client Hints, and unknown states
During migration, a server may receive only the legacy UA, both UA and Client Hints, or highly reduced forms of both. The data model should allow unknown rather than guessing an exact operating system or device model to fill every field.
4. Reduce log granularity
If analytics needs only desktop versus mobile, browser family, and major version, do not retain raw UA strings and every high-entropy hint indefinitely. Data minimization reduces privacy risk and prevents an analytics pipeline from treating minor variation as a meaningful dimension.
5. Treat anomalies as evidence, not verdicts
A UA that claims Windows while one API behaves differently is, at most, one risk signal. Enterprise environments, virtualization, remote sessions, compatibility layers, and assistive technologies can produce legitimate anomalies. Turning one mismatch into an automatic fraud decision creates false positives.
9. How should UA be configured in multi-profile environments?
For cross-region testing, advertising previews, account operations, and privacy isolation, the goal should not be to create the most unusual UA. A profile should be explainable, stable, and compatible with its surrounding environment.
Review the following in order:
- Browser version: the UA major version should be plausible for the actual engine and its capabilities.
- Operating system: the UA platform, Client Hints platform, and JavaScript-visible platform category should be compatible.
- Architecture and bitness: UA, Client Hints, and the executable environment should not make directly conflicting claims.
- Device form factor: a mobile declaration should make sense alongside touch support, viewport, pixel ratio, and interaction patterns.
- Regional context: language, timezone, geolocation, and proxy egress do not have to match mechanically, but they should make sense for the real workflow.
- Profile stability: when one account or test identity reuses a long-lived profile, avoid switching platform and major version without a reason.
PurpleMark's current profile conversion maps the selected operating system to a UA platform and first tries to extract the browser version from a configured Chrome/ or CriOS/ token. When no usable version exists, it derives a reasonable fallback from the current engine's major version. The purpose is not to spoof one isolated string, but to place UA configuration inside a consistent browser-profile model.
Profile isolation and parameter consistency can reduce technical correlation and testing bias. They cannot guarantee that accounts will never be linked, and they do not replace platform rules, account data, payment information, or responsible operating practices. Use these capabilities only for lawful privacy protection, authorized testing, and compliant business activity.
10. Frequently asked questions
Q1: Does changing UA turn the browser into another browser?
No. It changes part of what the client declares. It does not replace the JavaScript engine, rendering pipeline, network stack, or supported Web APIs.
Q2: Can a website read the “real UA”?
There is no universal hardware-level “real UA” that every website can bypass the browser to read. A site can nevertheless compare Client Hints, capability tests, and other fingerprint signals, find incompatible claims, and make a probabilistic inference.
Q3: Can a reduced UA distinguish Windows 10 from Windows 11?
The reduced legacy UA normally cannot do so reliably because both may report Windows NT 10.0. A browser that supports UA Client Hints may provide more detailed platform-version information after a site requests it. Servers must still handle missing fields and mapping differences.
Q4: Does disabling JavaScript stop UA exposure?
Not completely. The HTTP User-Agent is a request header and can be sent with the page request before page JavaScript runs. Disabling JavaScript removes some collection surfaces but also breaks substantial parts of the modern web.
Q5: Will Client Hints completely replace User-Agent?
Do not assume that in the near term. Many clients and servers still depend on the legacy UA, while UA Client Hints support varies. Treat Client Hints as progressive enhancement: prefer structured information when available, but retain fallbacks for legacy UA and unknown states.
Q6: Does a randomly generated UA improve anonymity?
Not necessarily. Randomizing one field can create contradictions with version, platform, touch, and rendering signals. For a long-lived profile, a common, stable, internally compatible configuration is usually more defensible than frequent random changes.
11. Conclusion
User-Agent is neither a trustworthy identity credential nor an irrelevant string. It sits at the intersection of web compatibility, privacy, and risk analysis. For developers, it is a compatibility input burdened by history. For fingerprinting researchers, it is an attribute with measurable statistical information. For browser vendors, it is a default exposure surface that needs to be reduced.
The key ideas fit into three statements:
- Do not read a UA literally; it contains many historical compatibility tokens.
- Do not evaluate UA in isolation; practical recognition comes from combinations of signals and their evolution over time.
- Do not think of Client Hints as merely “more UA fields”; their value lies in structured, request-driven, governable disclosure.
When a system moves from identifying a browser name to testing the capability it needs—and from collecting every available detail to requesting only what is necessary—UA returns to its proper role: a compatibility clue, not an identity truth.
References and standards
- Peter Eckersley. How Unique Is Your Web Browser?. Privacy Enhancing Technologies Symposium, 2010.
- Pierre Laperdrix, Nataliia Bielova, Benoit Baudry, Gildas Avoine. Browser Fingerprinting: A Survey. ACM Transactions on the Web, 2020.
- Antoine Vastel, Pierre Laperdrix, Walter Rudametkin, Romain Rouvoy. FP-Scanner: The Privacy Implications of Browser Fingerprint Inconsistencies. USENIX Security Symposium, 2018.
- Antoine Vastel, Pierre Laperdrix, Walter Rudametkin, Romain Rouvoy. FP-STALKER: Tracking Browser Fingerprint Evolutions. IEEE Symposium on Security and Privacy, 2018.
- IETF. RFC 9110: HTTP Semantics, 2022.
- IETF. RFC 8942: HTTP Client Hints, 2021.
- WICG. User-Agent Client Hints, Draft Community Group Report.
- Chromium. User-Agent Reduction.
- Chrome for Developers. Improve user privacy and developer experience with User-Agent Client Hints.