User Agent Parser

It is the line your browser puts in the User-Agent header of every request it makes, describing itself to the server. Press the button in the workspace above and this page reads it out of navigator.userAgent, then breaks it apart. Nothing is uploaded to do that; the reading happens in the tab. A typical one looks like Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/131.0.0.0 Safari/537.36, and of those six pieces only two, the platform comment and the Chrome version, tell you anything true. The rest is compatibility sediment that no browser dares remove.

Because of one decision in 1994 and thirty years of nobody being able to undo it. Netscape's internal codename was Mozilla and it sent Mozilla/2.0 as its identity. Servers started checking for it before serving frames, which Netscape supported and the competition did not. When Internet Explorer 2 gained frames it could not get the good page, so it sent Mozilla/2.0 (compatible; MSIE 2.0) and was served correctly. Every browser since has copied whoever was winning: Safari added Mozilla and KHTML, Chrome added Mozilla and Safari, Edge added Mozilla and Chrome and Safari. The prefix now means only that the sender is a web browser, and the 5.0 has not moved since 1998. Anyone who drops it finds some server somewhere serving them a 1999 page.

For the same reason Internet Explorer claimed to be Netscape. When Chrome launched in 2008 it used WebKit, the engine behind Safari, and a large amount of server side sniffing code was written as if WebKit meant Safari. Sending AppleWebKit and Safari tokens got Chrome the same pages Safari got, so it sent them. In 2013 Chromium forked WebKit into Blink, and it kept sending both tokens anyway, because by then removing them would have broken sites. So AppleWebKit/537.36 is a build number from the moment of the fork and no Chrome release in over a decade has contained that code, while Safari/537.36 is not a Safari that has ever existed. The practical consequence is that a parser must test for Chrome before Safari, or every Chrome user is counted as a Safari user.

Edg is Microsoft Edge built on Chromium, which is every Edge since 2020. It is spelled with three letters on purpose. The old Edge sent Edge/18.19041 and a large amount of feature detection code had been written to match the string Edge and treat it as the EdgeHTML browser with its own set of bugs. Shipping a Chromium browser that matched those checks would have handed it EdgeHTML workarounds it did not need, so Microsoft picked a token nothing was already matching. Edge on Android is EdgA and Edge on iOS is EdgiOS, which is a common gap in hand written parsers. In all three cases the token sits after a complete Chrome token, so a parser reading left to right and stopping at the first browser it recognises reports Edge as Chrome.

Because Apple decided in iPadOS 13 that an iPad should get desktop websites by default, and the way to make that happen was to send the desktop string. Safari on iPad now sends Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) with no iPad token in it, byte for byte identical to Safari on a Mac. There is no way to separate the two from the string, and that is deliberate. If you must know, the tell is in the page rather than the header: navigator.maxTouchPoints returns a number above zero on an iPad claiming to be a Mac, and zero on almost every real Mac. The iPad token only reappears when the user has chosen Request Mobile Website for that site.

No, and this is not a caveat, it is the defining property of the format. The string is chosen by the client. Changing it takes one field in the network conditions panel of any browser's developer tools, one -A flag on curl, or one line in any HTTP library. Nothing signs it, nothing verifies it, and nothing about the header travels with any guarantee. It is fine for analytics, where a small share of nonsense does not change the shape of the data, and for choosing a download link, where the worst outcome is the wrong installer. It is never acceptable as an access control, a licence check, a bot defence, or any other security decision. If you need to know that a request really is Googlebot, Google publishes reverse DNS ranges and a JSON list of its addresses for exactly that reason, and verifying against them is the only honest way to treat the claim.

They are the replacement for the whole format. Instead of one string carrying everything whether the site wants it or not, the browser sends three low entropy fields on every request (the brand list, whether it is mobile, and the platform name) and keeps everything else back until a site asks for it by name through the Accept-CH response header or through navigator.userAgentData.getHighEntropyValues in JavaScript. The high entropy values are the useful ones: the full browser version, the platform version, the architecture, the bitness, and the device model. Two details are worth knowing. The brand list deliberately includes one made up brand whose name changes every release, so that code has to parse the list properly rather than matching a single hardcoded name, which is precisely the mistake that made the old string impossible to fix. And support is not universal: Chromium browsers implement it, while Safari and Firefox have both declined to, which is why the old string is still what every browser sends.

It is Google's staged programme, largely complete since Chrome 110 in 2023, of freezing the parts of the string that made it a fingerprinting surface. Chrome now reports its minor, build, and patch numbers as 0.0.0, so the whole version reads 131.0.0.0 and only the major number is real. On desktop the platform version is pinned to a fixed value. On Android every device reports Android 10 and a model of K, whatever it actually is. Apple got there earlier and by a different route: macOS has reported 10.15.7 since Big Sur because so much sniffing code compared the version numerically and broke on 11, and the word Intel is still sent on Apple Silicon. The effect is that the string is now a much weaker signal than the code reading it usually assumes, and anything that needs the real values has to ask for them through Client Hints.

In Chrome and Edge, open developer tools, use the three dot menu to show More tools then Network conditions, untick Use browser default, and pick or type a string. Firefox exposes general.useragent.override in about:config. Safari has a Develop menu with a User Agent submenu. On the command line it is curl -A on curl and --user-agent on wget, and every HTTP library has an equivalent one line option. The legitimate uses are real: testing that your own site serves the right thing to an old browser, reproducing a bug that only a particular client sees, and checking what a crawler receives. What matters is the inverse. Since changing it is that easy for you, it is exactly that easy for everyone else, so no check you write on the server can assume the string is honest. Spoofing to evade a paywall or a rate limit is a terms of service problem rather than a technical one, and it usually fails anyway because serious systems stopped trusting the header years ago.

It is really Chrome's interface, its sync, and its address bar, and it is not Chrome's engine. Apple requires every browser on iOS and iPadOS to render with the system WebKit, so Chrome for iOS, Firefox for iOS, Edge for iOS, and Opera for iOS are all Safari underneath with different shells on top. The tokens are CriOS, FxiOS, EdgiOS, and OPiOS respectively, and each of them sits in a string that also carries AppleWebKit and a Safari build number, which are genuine in this case rather than decorative. The practical consequence for testing is the useful part: a rendering bug reported in Chrome on an iPhone is a WebKit bug, it will reproduce in Safari on the same device, and it will not reproduce in Chrome on any other platform. The European Union's Digital Markets Act has begun to loosen this, but outside that context the rule still holds.