User-Agent Explained: The "Identity Password" Hidden in Your UA String

Have you ever wondered: how does a website know whether you opened it on a Windows PC or an iPhone? Why do some sites automatically change their layout on mobile but show the full version on desktop?

The answer lies in a single line of code your browser sends automatically every time you open a webpage — the User-Agent, or UA for short.

For ordinary users, the UA is just data that flashes by when a page loads; for people running multiple accounts, this line of code is the "first clue" the platform uses to identify your device. This article breaks it all down: what exactly is written in the UA, what platforms do with it, and the pitfalls to avoid when changing it.

What is a UA string? How much information hides in one line of code?

In one sentence: the UA is a piece of "self-introduction" the browser attaches automatically to every page request — a few segments separated by semicolons that report the browser, OS, engine, and version.

Take a look at a real UA string:

Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/149.0.7827.54 Safari/537.36

Breaking it down, each segment means something:

• Mozilla/5.0: a historical "greeting" left over from the past; almost every browser carries it, so do not be misled by it.
• (Windows NT 10.0; Win64; x64): the OS is Windows 10/11, 64-bit. The content inside the parentheses directly exposes your system.
• AppleWebKit/537.36: the rendering engine declaration; Chromium-based browsers like Chrome and Edge all carry it.
• (KHTML, like Gecko): another historical leftover, meaning "the rendering behavior is similar to the Gecko engine."
• Chrome/149.0.7827.54: the browser brand and exact version — this is the segment platforms care about most.
• Safari/537.36: a masquerade tail that appears together with AppleWebKit.

See it now? The UA reports the OS, browser, engine, and version all at once — and it is completely passive: you did nothing, and it sent itself out.

Why does your UA say both Chrome and Safari?

You can blame a "history of masquerading" in the browser world — every browser today carries other names in its UA, all for compatibility with websites that made wrong judgments in the past.

The story dates back to 1996: back then, the Netscape browser's UA started with "Mozilla," and many websites only recognized this identifier, treating every other browser as "unsupported weirdness." To avoid being shut out, IE added the words "Mozilla/compatible" to its UA. Later Firefox, Chrome, and Safari followed suit one after another, and everyone ended up putting each other's names in — creating today's spectacle where "everyone is Mozilla, everyone is Safari."

Chrome's UA carries Safari not because they are related, but because in the early days some websites only offered full functionality to Safari. This history has made the UA field seriously distorted — it is neither fully trustworthy nor unique.

What do platforms do with the UA? Why is it only "supporting evidence"?

Platforms read the UA mainly for three things:

• Determine the device type: whether you are on mobile or desktop, iOS or Android, which decides which version of the page to show you.
• Determine the browser version: browsers that are too old get a direct "please upgrade" prompt, while versions that are too new may still be in gray-scale testing.
• Cross-check against the real fingerprint: this is what multi-account operators need to watch most — when the UA says Windows + Chrome, the platform checks whether your Canvas, WebGL, and font list also look like Windows + Chrome. Browser fingerprinting is the whole picture of dozens of parameters (the overall concept is explained in this browser fingerprinting guide), and the UA is just the most "surface-level" item among them.

Here is the key: the UA is a "declared value" that can be changed freely; while Canvas, WebGL, and others are "measured values" read from real hardware (the principle is covered in this WebGL fingerprint guide). Platforms never trust only the UA — they trust whether "the UA matches the other parameters." When the declaration and the measurements agree, you are a normal user; when they conflict, you become a person of interest.

Here is the most common contradiction: the UA says iPhone, but the screen resolution is a 1920×1080 desktop display — this kind of tell is even easier for risk control to catch than the "UA exposure" itself.

What is the right way to change the UA?

Many people's first instinct is to install a plugin to change the UA, but a plugin only changes the "declaration" layer. To change it "seamlessly," you need to change the parameters that pair with the UA together — and this is exactly what a fingerprint browser excels at. Taking MasBrowser as an example, when creating an environment you can configure the UA and operating system independently in the fingerprint settings; if you choose Windows as the system, the UA automatically matches with a Windows version combination, and the language, time zone, and screen resolution all sync together — no "declaration vs. measurement" conflicts. For the full independent environment and fingerprint isolation configuration, see the MasBrowser multi-account security management page.

How do you verify the change is correct? Open any fingerprint detection website (Browserscan, etc.) inside the environment and check whether the UA column is consistent with the system, language, and time zone.

The 3 most common mistakes when changing the UA

Even with a fingerprint browser, people still trip up when configuring the UA:

• Version number too new or too old. A UA claiming a Chrome version newer than the latest release, or stuck at a version from two or three years ago, is an abnormal signal. Using the version range currently mainstream in your target market is the safest.
• Mobile UA paired with a desktop screen. The UA claims iPhone, but the screen resolution is a desktop monitor — this contradiction is caught in a second. The device type must match the resolution and touch capabilities.
• UA mismatched with system and region. The proxy IP is from the US, but the UA is Chinese-language Chrome with a Chinese language list — the platform immediately sees the mismatch during cross-checking. The UA, system, language, time zone, and IP must all present the profile of "a person from the same region."

Remember one principle: the UA itself is not the point — "whether the UA is consistent with the other parameters" is the point. A consistent UA is the least conspicuous UA.

Frequently asked questions

Can I avoid being identified just by changing the UA?

Not by itself. The UA is only a "declared value," and platforms cross-check it against "measured values" like Canvas, WebGL, and fonts. Changing only the UA without the matching parameters actually makes the "declaration vs. measurement contradiction" easier to expose.

Does incognito mode change the UA?

No. Incognito mode only stops saving browsing history and cookies; the UA is still sent according to the browser's real information — this follows the same logic as browser fingerprinting and does not change the UA itself.

Which is better, mobile UA or desktop UA?

It depends on your target market and platform. The key is "consistency": if you choose a mobile UA, the screen resolution, touch capabilities, language, and time zone should all look like a phone; if you choose a desktop UA, configure the whole set as a desktop. Mixing is the biggest tell.

Can the platform see that I changed the UA?

Platforms cannot see the "trace of modification," but they can see "inconsistency." The UA itself can be changed; the problem is not leaving contradictions after changing it — which is exactly why fingerprint browsers configure the UA, system, language, and time zone in sync.

Conclusion

The UA is an "identity card" the browser proactively sends on every visit, full of information about your system, browser, and version. For historical reasons it looks the same on everyone yet different for everyone — it is the "first clue" platforms use to identify devices, but never the only basis: what platforms really look at is whether the UA is consistent with the rest of the fingerprint parameters.

So what multi-account operators need to do is not "hide the UA," but "make the UA consistent with the whole environment." The free plan already includes 2 environment slots — download MasBrowser, create an environment and see how the UA, system, and language are configured in sync. This step will make every one of your accounts look like "a normal user."