THE PRACTICAL GUIDE · NORMANDIN SYSTEMS
Get more from User-agent parser
User-Agent Parser interprets a user-agent string into supported browser, rendering engine, operating system, CPU, and device information. User-agent strings are conventional labels sent by clients and often contain compatibility tokens. Parsing helps organize diagnostics, but the values can be reduced, spoofed, or ambiguous and should not be treated as reliable proof of device identity or capabilities. Inspection tools turn technical information into a form you can examine and compare. Their reports describe the input or the environment they can observe, so missing fields and implementation limits matter as much as populated values. Start with an example whose basic properties you already know, then investigate unfamiliar values one at a time. Save relevant observations alongside the context in which you collected them. A report is evidence for troubleshooting, rather than an automatic explanation of every underlying problem.
Guide updated October 13, 2026
How to use this tool
- Provide the relevant sample or open the workspace in the environment you want to inspect. Note the source and context of the information.
- Paste the complete user-agent string and compare the parsed fields with the actual client context if it is known.
- Review the example below and compare its expected behavior with a small sample of your own input before continuing.
- Compare the important fields against your expectations and investigate discrepancies using a second relevant source of evidence before drawing conclusions.
SEE IT IN PRACTICE
A worked example
A browser user-agent string containing recognizable browser and operating-system tokens
Structured fields for the browser and operating system where recognized
The parser identifies patterns in the supplied text; it does not query the device or verify the string's origin.
Compatibility tokens can be misleading
User-agent strings often contain several browser or engine names for historical compatibility. Reading the first familiar token by hand can therefore identify the wrong client. A parser applies patterns to interpret the string, but it still depends on the supplied text and its known conventions. Reduced user-agent data may omit detailed versions or device models, and an unknown field is a legitimate result. Preserve the original string beside the parsed report when investigating an unexpected classification.
Use capabilities for behavior decisions
A reported browser family is a weak substitute for checking whether the actual feature your application needs is available. Spoofing, embedded webviews, backported features, and privacy changes all complicate name-based assumptions. Use the parsed report for diagnostics and broad context, then test behavior directly when deciding how the application should work. Do not treat a device label as authentication or identity evidence. A client can supply an arbitrary user-agent string, so the parser's structured output is interpretation rather than verification.
When this tool is useful
- Interpret a browser string from a bug report
- Review user-agent parsing results
- Compare client labels during compatibility troubleshooting
Tips for a better result
- Check unknown or ambiguous fields and compare with actual browser behavior rather than assuming every client exposes a full model or version.
- A missing field can mean the information was absent, unsupported, or deliberately withheld. Do not silently treat an unknown value as a negative result or as zero.
- Keep the source and the settings used for this result together. That makes a later comparison or correction easier, especially when another person needs to reproduce the same outcome.
Frequently asked questions
Does a browser label prove feature support?
A parsed browser name does not guarantee support for a particular web feature. Prefer feature detection for application behavior where practical.
Does a report prove that everything is correct?
No. A report exposes particular properties that the tool can inspect. Interpret each field in context, consider what was not checked, and use the result together with the original file or system evidence.
How can I make comparisons more reliable?
Compare like with like: use the same input version and note browser, device, or file differences that may affect the report. Change one variable at a time so you can identify which change explains a different result.
What happens to the information I enter?
The utility processes your input in this browser. Some tools retain field values in browser storage or the URL; avoid entering secrets in shareable fields. Page and asset requests still go to the hosting provider. Read the privacy and offline-use notes for details.