Most user agent strings that get flagged as fake aren't flagged because the string itself is malformed — they're flagged because something about the combination doesn't add up. A well-formatted string built from an impossible pairing is often more obvious than a slightly malformed one, because inconsistency is exactly what basic detection logic looks for.
Impossible platform and browser pairs
Safari hasn't shipped a Windows build since version 5, back in 2012. A user agent claiming to be Safari running on Windows is immediately suspicious to anything that checks — it's a combination that essentially doesn't occur in real traffic anymore. The same logic applies in reverse to a lesser degree: Internet Explorer-style tokens on macOS, or old mobile Safari formats on a desktop platform string. These pairings aren't just uncommon, they're close to nonexistent, which makes them cheap to detect with a simple lookup table.
Version numbers that don't exist together
Browser engine versions and browser product versions move together in a fairly predictable way — a given Chrome release always ships with a specific, matching version of the underlying rendering components. A string that pairs a very recent browser version number with a rendering engine token from several years earlier doesn't match any real release. It's a subtle mismatch, but it's exactly the kind of thing a more thorough check cross-references.
Stale versions presented as current
A user agent claiming to be the "latest" version of a major browser, dated from three years ago, ages out quickly. Browsers push updates frequently, and most real-world traffic clusters tightly around whatever the last handful of releases were. A single outlier isn't necessarily suspicious on its own, but at any real scale, a wave of traffic all reporting the same multi-year-old "latest" version is a very easy pattern to spot.
A user agent that doesn't match anything else about the request
This is the one that matters most and is the hardest to fix by editing a single header. A user agent claiming to be mobile Safari on an iPhone, arriving with desktop-shaped headers, no touch-event support, and a screen size reported nowhere near any real iPhone, isn't consistent — and inconsistency, not the string itself, is what most detection actually keys on. See our piece on user agents versus fingerprinting for the fuller list of signals a mismatch like this can trip.
Reusing the exact same string at high volume
Real browser traffic naturally varies — different users are on different patch versions, different builds, different minor OS revisions. A large volume of requests all presenting the identical user agent string, character for character, looks synthetic in a way that no individual string does. If a workflow needs multiple requests to look like ordinary traffic, varying the version and build details across requests is part of what makes that plausible — which is part of why generating a batch with some natural variation, rather than reusing one string everywhere, holds up better under any real scrutiny.
The pattern behind all of these
Every example here comes down to the same thing: one detail alone rarely gives anything away, but two details that contradict each other do. A user agent claiming a device it doesn't run on, a version that doesn't exist, or timing that doesn't vary like real traffic — each is a small crack, and detection systems are generally built to notice cracks, not to grade individual strings in isolation.