How to Read the User Agent in a Customer's Bug Report and Reproduce Their Problem

A customer writes in: "Your site is broken on my phone." No screenshot, no error message, no browser name. The fastest way out of that dead end is usually sitting right there in the report, in a line most people scroll past: the user agent string. Learn to read it and you can work out the browser, operating system and device the customer was using, then reproduce the problem yourself.

What a user agent string actually is

Every time a browser loads a page, it introduces itself with a short line of text naming the browser and its version, the operating system, and usually whether the device is a phone, a tablet or a desktop. Websites use it to serve the right layout, and support teams use it to match a bug to a setup. Here is a real one, from Chrome on Windows:

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

It looks like noise, but it is a parts list. Mozilla/5.0 says nothing about the browser. It is a compatibility token every major browser sends for historical reasons. The useful parts come after it: Windows NT 10.0 is the operating system, AppleWebKit/537.36 is the rendering engine, and Chrome/154.0.0.0 is the browser and its major version. The Safari/537.36 at the end is another leftover from the days when browsers copied each other to get better pages. Ignore the names that repeat, and read the most specific one.

Paste the string from a bug report into our User-Agent Parser and it breaks the line into those plain parts for you. You do not need to memorise the tokens. You do need to know which parts you can trust, because some of them stopped telling the truth years ago.

The three traps that catch everyone

First, version numbers in Chrome are mostly frozen. Since Chrome finished its user agent reduction in 2023, the minor, build and patch numbers are always 0.0.0. Only the major version is real, so Chrome/154.0.0.0 tells you the customer is on Chrome 154 and nothing more precise. If a bug only appears in one small Chrome update, ask the customer to read the version from their browser settings.

Second, operating system versions are frozen too. Windows 10 and Windows 11 both report Windows NT 10.0, so no parser can tell them apart. Macs report 10_15_7 whatever version of macOS is actually installed, Android reports Android 10 followed by a K where the device model used to sit, and Safari on iPhones and iPads now reports a frozen iOS version as well. The string still tells you the operating system family, which is usually enough to reproduce a layout bug, but not the exact release.

Third, every browser on an iPhone is Safari underneath. Apple requires all iOS browsers to use its WebKit engine, so Chrome, Firefox and Edge on an iPhone all render pages like Safari. If the string says CriOS, that is Chrome on iOS, but a bug that appears in Chrome on an iPhone will usually appear in Safari on the same phone too. Test on iOS Safari and you have tested them all.

A worked example, start to finish

Say a report arrives with this string:

Mozilla/5.0 (Linux; Android 10; K) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/154.0.0.0 Mobile Safari/537.36

Read it left to right. Linux; Android 10; K means an Android phone, with the model deliberately hidden. Chrome/154.0.0.0 means Chrome, major version 154. The word Mobile confirms it is a phone, not a tablet in desktop mode. In under a minute you know the reproduction setup: Chrome 154 on an Android phone. The phone model and Android version stay hidden, and for most layout bugs you do not need them.

How to reproduce the problem once you have read it

Work in this order. First, paste the string into the User-Agent Parser and write down the four facts: browser and major version, operating system family, mobile or desktop, and engine. Second, open the same browser and version on your own machine, or the nearest you have. If the report is mobile and you have no matching phone, use your browser's developer tools to emulate the device size and the mobile user agent. Emulation catches most layout and touch problems, and it costs nothing.

Third, follow the customer's steps exactly, on the same kind of page they were on. If the bug does not appear, check the two things the string cannot tell you: the exact browser minor version and the screen size. Ask the customer for those two facts specifically, not for "more details". A precise question gets a precise answer. Fourth, if the string is missing entirely, ask the customer to visit a page that shows their own user agent. Most people have never seen the string, so give them a link rather than instructions.

One more check worth doing: look at what the customer was doing, not just what they were using. A bug that appears only when a page is opened inside an app, like the browser inside Facebook or Instagram, often comes with a user agent that names the app. Those in-app browsers behave differently from the standalone browser on the same phone, so reproduce the bug by opening the link inside the app, not in Chrome or Safari.

What the string cannot tell you

The user agent is a self-declared label, not proof. It can be faked in seconds with a browser setting or an extension, and bots routinely send strings that claim to be ordinary browsers. Never use it as evidence of who someone is, only as a clue about what software they were running. It also says nothing about screen size, extensions, or whether JavaScript was blocked. If a bug only appears for one person and you cannot reproduce it on their stated setup, extensions and ad blockers are the next suspects. For more on what your own browser tells every site, read Your User Agent Is Telling on You.

What to do first

The next time a vague bug report lands, do not reply asking which browser the customer uses. Ask for the user agent string, or find it in the report if it is already there, paste it into the User-Agent Parser, and write the four facts on a sticky note: browser and version, operating system, mobile or desktop, engine. Then reproduce the problem on that setup before you write a single line of fix. Most "works on my machine" mysteries end right there, in the thirty seconds it takes to read one line properly.