🔧 TL3 Tools

What This Parser Reads

The User Agent Parser extracts browser name, browser version, operating system, and device type from any user agent string. It automatically loads your current browser's user agent and parses it immediately. You can also paste any custom user agent string to analyze other browsers, bots, or devices. The parser uses a series of pattern-matching rules to identify the browser engine, version numbers, OS family, and device category (desktop, mobile, or tablet). All processing is client-side with no data sent to any server.

Pasting a User Agent

1. Load your browser — your current user agent is automatically displayed in the read-only field.
2. Click Parse — the tool shows your browser, version, OS, and device type immediately.
3. Or paste a custom UA — enter any user agent string in the textarea and click Parse to analyze it.
4. Read the results — parsed details are displayed in a clean card layout with labels for each field.

Who Works With User Agents

• Web developers — verify user agent detection logic when building browser-specific features or fallbacks.
• QA engineers — test how your application identifies different browsers and devices during cross-browser testing.
• Support teams — ask users to paste their user agent string for troubleshooting browser-related issues.
• Security analysts — inspect user agent strings from server logs to identify unusual browser patterns or bot traffic.

User Agent Questions

How accurate is the user agent parser?

The parser uses pattern matching against known browser, OS, and device signatures. It covers the major browsers (Chrome, Firefox, Safari, Edge, Opera), operating systems (Windows, macOS, Linux, iOS, Android), and device types. For less common browsers or obscure user agents, results may be less accurate. User agent strings can be spoofed, so treat the output as a best-effort identification.

Can I use this to detect bots and crawlers?

Many bots and crawlers include identifiable strings like Googlebot, Bingbot, or Slurp. The parser will attempt to identify common crawlers by name. For comprehensive bot detection, consider combining user agent analysis with IP reputation checks and behavioral signals.

Why am I seeing "Unknown" for some fields?

The parser may not recognize every possible browser, OS, or device combination. This is especially common for esoteric browsers, custom user agent strings, or future browser versions. You can still see the raw user agent string and manually interpret the remaining details.

Is user agent detection still relevant in modern web development?

While feature detection (checking for specific browser capabilities) is generally preferred over user agent sniffing, user agent analysis remains useful for analytics, logging, and certain edge cases where feature detection is impractical or impossible.

Reading a User Agent, Step by Step

A user agent string is a series of product tokens separated by spaces. The parser works through them left to right and pulls out four facts. Take a typical desktop Chrome string:

Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/126.0.0.0 Safari/537.36

• Browser: the Chrome/126.0.0.0 token wins the browser check, and the version is read straight from that token.
• Operating System: the Mac OS X 10_15_7 segment inside the parentheses maps to macOS, with underscores translated to dots so it reads 10.15.7.
• Device Type: no Mobile or iPad marker is present, so the result falls back to Desktop.
• Compatibility tokens: Mozilla/5.0, AppleWebKit/537.36, and like Gecko are historical markers — Safari adds Version/17.5 plus its WebKit token, which is why Safari detection reads the Version/ token rather than a Safari/ one.

Bots and Crawlers

Search engine crawlers announce themselves openly. When the string contains Googlebot, Bingbot, or Slurp, the parser names the crawler and flags the Device Type as Bot. This is handy when you are auditing server logs and want to separate genuine browser traffic from crawler hits.

What the Tokens Mean

Decode the example left to right. Mozilla/5.0 is a legacy compatibility marker dating back to the browser wars of the nineties — nearly every browser ships it so that ancient servers respond with standards mode rather than quirks mode. The parenthesized section names the platform: Macintosh, Intel Mac OS X 10_15_7, and the architecture when the client reports one. AppleWebKit/537.36 is the rendering engine, (KHTML, like Gecko) a second compatibility claim, then the real product — Chrome/126.0.0.0 — and finally Safari/537.36, which Chrome appends because WebKit-derived engines do.

Mobile browsers add extra markers such as Mobile Safari or Chrome Mobile, plus tokens naming the phone model on some Android builds. The order of tokens is not legally fixed, and vendors occasionally reorder fields between releases, which is why substring matching is fragile and the parser instead scans for known product names in any position.

Known Limitations

• User agents can be spoofed. Any client can send any string, so treat the output as best-effort identification, never as a security boundary.
• Unknown fields. Obscure browsers, future versions, or trimmed strings show Unknown where a match is missing — the raw string stays visible so you can interpret it yourself.
• Windows version mapping. The Windows NT 6.3 style tokens map to marketing names (Windows 8.1, 8, 7, and so on); Windows NT 10.0 covers both Windows 10 and 11, which send identical strings.
• Nothing leaves your browser. Parsing is pure pattern matching in JavaScript, so the strings you analyze are never transmitted anywhere.

When to Trust the Result

The parser is most reliable for the mainstream combinations — Chrome, Firefox, Safari, Edge, and Opera on Windows, macOS, Linux, iOS, and Android — and for the well-known crawlers. For analytics, log triage, and support diagnostics, that coverage is plenty. If you are building a security gate or a paywall, never key off the user agent alone; pair it with feature detection or server-side signals.