What to do when a User-Agent parser is inaccurate: common misclassifications and troubleshooting

Plenty of people hit this when they use an online User-Agent parser: the PC is clearly running Windows 11, but the result comes back as Windows 10. Same browser, different websites, and the device and OS details don't quite match either.

Most people's first reaction is that the parser is wrong. In fact, a mismatch in UA parsing doesn't necessarily mean the tool is broken. A User-Agent is just a string the browser volunteers, it's packed with legacy compatibility markers, and modern browsers are steadily cutting back how much information the traditional UA can still deliver.

So to judge whether an online User-Agent parse is accurate, don't stop at the "browser / OS / device" verdict it prints. Read it alongside the raw UA and the other browser data.

1. Why User-Agent parsing goes wrong so easily

UA was originally all about browser compatibility. So that old sites could recognise new browsers, the major browsers kept a pile of legacy fields around for years and years.

Take a typical Chrome UA:

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

Here Mozilla/5.0 doesn't mean the browser is Firefox, and "like Gecko" doesn't mean it runs the Gecko engine. The Safari/537.36 tacked onto the end of Chrome is another compatibility marker, it doesn't mean you're on Safari either.

So a parser that just matches keywords can easily label Edge, Opera and other Chromium browsers as Chrome, or read certain in-app browsers as Safari.

2. Change the UA and the parse changes with it

The device-emulation mode in DevTools, some browser extensions and certain compatibility settings can all change the User-Agent a page actually reads.

If the UA the browser hands over doesn't match the real machine, a parser working off that string will naturally land somewhere else.

So when the "real device" and the "parsed result" disagree, check whether the UA itself is genuine first, instead of assuming the tool got it wrong.

3. Why does Windows 11 so often show up as Windows 10?

This is the textbook case in the wake of UA reduction.

On Windows, Chromium browsers normally put this in the traditional UA:

Windows NT 10.0

So even when the machine is really on Windows 11, the traditional User-Agent alone usually can't tell Windows 10 and Windows 11 apart.

That's not necessarily a parsing error, it's that the traditional UA simply doesn't carry enough information.

Modern browsers have started exposing more structured data through User-Agent Client Hints, for example:

Sec-CH-UA
Sec-CH-UA-Mobile
Sec-CH-UA-Platform
Sec-CH-UA-Platform-Version

Front-end code can also pull some of this from navigator.userAgentData. Which means if you want an accurate read on the browser environment, navigator.userAgent on its own is no longer enough.

4. Why in-app browsers are so easy to misidentify

When a page opens inside a mobile app, it may well be running in a WebView. These UAs usually append the app name, version and similar fields after the browser info.

If the parsing library is working from outdated rules, you get "unknown browser", the wrong device brand, missing version numbers and so on.

Beyond that, a request can pass through a CDN, a corporate gateway or another intermediary before it reaches the server. If any hop rewrites the headers, the UA the server ends up logging may differ from what the browser originally sent.

So when the UA in the local browser and the UA in the server logs don't match, first confirm the server is actually receiving the original request headers.

5. How should you troubleshoot an inaccurate UA parse?

Start with the complete raw UA, not just the tool's one-line summary of "Chrome, Windows, PC". Only the full string tells you whether the problem sits in the data or in the parsing rules.

Then check Client Hints. Put navigator.userAgent, navigator.userAgentData and the Sec-CH-UA family of headers the server received side by side and compare them.

Next, cross-check. Look at screen resolution, device pixel ratio, system language, timezone and browser fingerprint. When several dimensions line up with each other, the parse is usually worth trusting.

Finally, don't overlook the network environment as a whole. You can use ToDetect to check IP ownership, DNS and browser fingerprint at the same time, then come back to the UA. That helps you work out whether it's a UA data problem or a difference created by the browser or the network.

6. User-Agent online parsing: frequently asked questions

Q1: The online User-Agent parse doesn't match what I see locally. Which one is wrong?

Not necessarily either. Locally you're reading the current browser environment, while what the server records may have gone through a cache or an intermediary. Start by comparing the raw request headers the browser actually sends against what the server actually receives.

Q2: Why does Windows 11 show up as Windows 10?

Because the traditional UA normally uses Windows NT 10.0, and that field on its own can't reliably separate Windows 10 from Windows 11. If you need a finer read, bring in Client Hints.

Q3: Can UA parsing pin down the exact device model?

Not from UA alone. Device model is a finer-grained signal, so it's best to combine Client Hints, browser parameters and other environment characteristics.

Q4: Is it normal for the same device to parse differently at different times?

It can be. Browser updates, changed settings, a different page context, even a different request path can all change the final result.

Q5: What matters most when choosing a User-Agent parser?

How often the rule library is updated, whether it supports Client Hints, and whether you can see the full raw UA. If you can see the raw data, you can keep troubleshooting when something looks off.

The bottom line

A User-Agent is better treated as a clue than as proof of what the device actually is. Traditional UAs carry a lot of legacy compatibility noise, and modern browsers keep reducing the system detail they expose, so a certain amount of discrepancy is no surprise.

When a UA parse really does look wrong, verify the raw data first, then check the parsing rules, and finally validate against Client Hints and the rest of the browser environment. That gets you to the actual cause far faster than simply swapping in another parser.