User-Agent Parser

Every browser request carries a user-agent string, a dense little declaration of browser name, rendering engine, operating system, and device, and most people only ever see it as an opaque wall of Mozilla/5.0 noise. The User-Agent Parser unpacks that wall in real time. Paste any string, or hit the Use my User-Agent button to capture your own browser's value from navigator.userAgent, and the tool immediately reports the browser name and version, the operating system with its release number where available, the underlying rendering engine such as Blink, Gecko, WebKit, or Trident, and a device-type classification of desktop, mobile, or tablet with a matching icon. The raw string is echoed back in a card below so nothing gets lost, and a Clear button resets the field whenever you are ready for the next one. Recognition covers Chrome, Firefox, Safari, Edge, Opera, Samsung Internet, and legacy Internet Explorer across Windows, macOS, iOS, iPadOS, Android, ChromeOS, Linux, and FreeBSD. Support teams triaging bug reports, web analytics folks cleaning browser dimension data, and QA engineers verifying what a client is actually sending will all find this browser detection utility a fast, local, and free way to decode UA strings.

1. 1

   The field auto-fills with your own navigator.userAgent on load; replace it by pasting any string into the User-Agent string textarea.

2. 2

   Click Use my User-Agent to restore your browser's current string, or Clear to empty the field.

3. 3

   Read the Browser, Operating System, and Engine stats; the browser value includes its version when one is detected.

4. 4

   Check the Device type card for Desktop, Mobile, or Tablet with a matching icon.

5. 5

   Scroll to the Raw User-Agent card to review the exact input you parsed.

• Decoding the UA string from a support ticket to confirm which browser and OS a customer used.
• Classifying traffic patterns during a bug investigation when analytics says "browser: unknown".
• Verifying bot or crawler user-agents to decide whether a client deserves human-or-bot treatment.
• Testing how your analytics or server-side logic will classify a new device before rolling out device-based logic.
• Teaching junior engineers to read UA tokens instead of trusting vendor-prefixed browser detection.
• Comparing the UA sent by different browser modes, such as Safari's desktop-on-iPad request, using the tablet classification.

• Never use UA parsing for security decisions; every token in the string can be spoofed with a single curl flag.
• Treat the engine result as advisory, because browsers fake each other's engines for compatibility, which is why Chrome strings mention Safari.
• Prefer feature detection in your own code and use tools like this only for diagnostics and analytics context.
• Record the full raw string in bug reports, not just the parsed summary, so the exact tokens remain available for re-analysis.
• Re-parse old strings when investigating historical traffic; conventions like Windows NT 10.0 change meaning over time.
• Sanitize UA strings before storing them in logs; long spoofed strings carry noise, and truncating keeps dashboards readable.

• Load the page from a phone or tablet and click Use my User-Agent to see your real mobile string parsed.
• Paste several strings in a row and compare engine results to internalize how Chrome, Firefox, and Safari differ.
• Clear the field before each new string to avoid mixing partial pastes.
• Keep the Raw User-Agent card in mind for screenshots; it proves exactly which string produced the result.