Swap a browser's user agent string and, on the surface, it looks like a different browser just showed up. Underneath, almost nothing else changed — and that gap between "looks different" and "is different" is exactly what browser fingerprinting exploits.
What a user agent actually covers
A user agent string reports one thing: what the browser claims to be. It's a self-declared label, sent as a plain HTTP header, and a server has no independent way to verify it's telling the truth. That's precisely why it's the easiest signal to change — and also why sites that care about knowing who's really visiting stopped relying on it alone years ago.
What fingerprinting looks at instead
Browser fingerprinting builds a profile from characteristics that are much harder to fake convincingly all at once: screen resolution and color depth, installed fonts, the specific set of browser plugins and extensions, timezone and language settings, how the browser renders a canvas element (which varies subtly by GPU and driver), WebGL renderer details, and the exact set of HTTP headers sent alongside the user agent, in the order they're sent. Individually, most of these are common. Combined, they narrow down to a small group of devices — sometimes a single one — even without cookies.
Why a mismatched setup is worse than no disguise at all
Here's the part that trips people up: claiming to be Safari on an iPhone while every other signal — canvas rendering, font list, WebGL output — matches a Windows desktop running Chrome doesn't make a site think "this is an iPhone." It makes the mismatch itself the signal. A real iPhone doesn't have a Windows-style font list. A site that's watching for inconsistency now has a much stronger reason to flag the visit than if the user agent had just been left alone. This is part of what our guide to common mistakes covers in more detail — the giveaway usually isn't the string itself, it's the string next to everything around it.
Where a user agent change is genuinely useful
None of this means changing a user agent is pointless — it's just narrow in scope. It's genuinely useful for triggering the code path a site serves to a specific browser or device (checking a mobile layout without a physical phone, confirming a feature check degrades gracefully on an older browser version), and for any testing where the site is deliberately branching based on that one header. It's not a substitute for testing on a real device when rendering, touch behavior, or performance actually matter, and it does very little on its own against a site that's actively fingerprinting.
The practical takeaway
Think of a user agent string as one line on a form, not a disguise. It's useful for telling a server which version of a page to send, and for basic compatibility testing. If the goal is genuinely appearing as a different device end to end, the user agent is the smallest part of that picture — screen size, fonts, and rendering behavior all have to line up too, and most testing setups don't need to go that far to get a useful answer.