🔍 User-Agent Parser

Parse User-Agent strings into browser, OS, engine, and device hints in your browser.

Last updated: June 9, 2026 · By Λ

Browser-
Browser Version-
Operating System-
OS Version-
Rendering Engine-
Device Type-
Bot Signature-
Platform-
Paste a User-Agent string and click Parse.

What is a User-Agent Parser?

A User-Agent parser reads the User-Agent header sent by browsers, bots, and apps, then extracts structured fields like browser family, version, operating system, device type, and rendering engine, turning a dense raw string into usable metadata for debugging, analytics, and access control work.

Web teams use this data to investigate compatibility problems, identify unusual traffic patterns, and improve device-specific user experiences. For example, if a support ticket reports a broken UI, parsing the reported User-Agent quickly reveals whether the issue comes from an older Safari release, a niche Android browser, or an automated crawler.

The output here is a JSON summary you can copy into issue trackers, docs, or tests, with heuristic bot detection and basic platform classification included.

How to Use This Tool

  1. Paste a User-Agent string into the input area, or load a built-in sample.
  2. Click Parse to extract browser, OS, engine, and device information.
  3. Review the result grid to inspect classified values quickly.
  4. Copy the generated JSON when sharing findings with your team.
  5. Repeat with additional strings to compare environments and clients.

Key Features

How the Matching Rules Work

The parser is a small stack of ordered regular expressions, and the order is what makes it accurate. Browser detection tests Edg/ before OPR/, and both before Chrome/, because a modern Edge string carries Chrome and Safari tokens simultaneously; the first rule that fires wins and its capture group becomes the version. Windows NT numbers go through a lookup table (NT 10.0 reads as 10/11, NT 6.3 as 8.1, NT 6.1 as 7), and underscored Apple versions become dotted ones. The engine cell is inferred: AppleWebKit plus a Chrome token means Blink, AppleWebKit alone means WebKit, Gecko with Firefox means Gecko, Trident means legacy IE. Device type checks bot tokens first (bot, spider, crawl, slurp, bingpreview, facebookexternalhit, discordbot), then tablet, then mobile, then defaults to Desktop. Edits to the input re-parse automatically after a 300 ms pause.

Worked Example

Load the built-in Chrome on Windows sample: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/124.0.0.0 Safari/537.36. The grid fills with Chrome 124.0.0.0, Windows 10/11, Blink, Desktop, 64-bit, and No bot signature. The Googlebot sample instead returns Unknown for browser, Bot for device type, and Likely bot for the signature.

Known Blind Spots

Brave, Vivaldi, and most Chromium shells ship a stock Chrome UA, so they classify as Chrome; that is the vendors' choice, not a parsing bug. Windows 11 cannot be told apart from 10 because both send NT 10.0. An iPad in desktop-site mode presents a Macintosh string and lands as macOS Desktop. Chromium's UA reduction also freezes minor version digits at zero, so trust the major version and treat everything else as a hint.

Frequently Asked Questions

Are User-Agent strings always reliable?

No. They can be spoofed or modified by clients and proxies, so they should be considered hints, not strong identity signals.

Why does one browser include other browser names in UA text?

Many browsers include compatibility tokens such as "Mozilla" or "Safari". Parsers must apply ordered matching rules to classify correctly.

Should I block bots based only on User-Agent?

No. Combine User-Agent checks with IP intelligence, behavior analysis, and rate limiting for reliable bot mitigation.

Does this parser send data to a server?

No. The regex rules run against the pasted string on your own device, so the User-Agent text you analyze is never transmitted anywhere.

Related tools