User-Agent Parser – Decode Browser, OS, and Device from Any UA String
Every HTTP request carries a User-Agent header — a text token that identifies the client making the request. Browsers, crawlers, mobile apps, and command-line tools all send their own UA strings, and decoding those strings by hand is error-prone. This tool parses any User-Agent string instantly in your browser, extracting the browser name and version, rendering engine, operating system, device type, and whether the client is a bot or crawler.
What Is a User-Agent String?
A User-Agent string is a short piece of text sent automatically in theUser-Agent HTTP request header. The format was originally defined in RFC 1945 (HTTP/1.0) and has evolved significantly since. A typical modern UA string looks like:
Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/124.0.0.0 Safari/537.36
This single line encodes the browser name (Chrome 124), the platform (Windows 10/11 64-bit), and the underlying rendering engine (Blink / WebKit). The legacy Mozilla/5.0 prefix and mentions of Safari are compatibility artefacts from the browser wars of the 1990s — virtually every browser still includes them.
Why Parsing User-Agent Strings Is Tricky
UA strings were never designed as structured data. Browsers include tokens from competing browsers intentionally so that servers do not block them for being "unknown". This means:
- Chrome includes "Safari" — because early WebKit-based browsers needed the Safari token to receive proper responses from servers that only knew Safari.
- Edge includes "Chrome" — because Chromium-based Edge uses the same Blink engine, and many sites have Chrome-specific optimisations.
- Almost every browser includes "Mozilla/5.0" — a historical compatibility fragment from Netscape Navigator.
Reliable parsing therefore requires matching tokens in a specific order — more specific identifiers (like Edg/ for Edge) must be checked before generic ones (like Chrome/).
Fields Detected by This Tool
- Browser name and version — Chrome, Firefox, Safari, Edge, Opera, Samsung Internet, Brave, Vivaldi, UC Browser, and many more.
- Rendering engine — Blink (Chromium), Gecko (Firefox), WebKit (Safari), Trident (Internet Explorer), EdgeHTML (legacy Edge), or Presto (old Opera). The engine version is extracted where available.
- Operating system and version — Windows (with NT version mapped to marketing name), macOS, iOS, iPadOS, Android, ChromeOS, and Linux distributions.
- Device type — desktop, mobile, tablet, or bot. Detection uses keywords like
Mobile,Tablet,iPad, and Android viewport hints. - Device vendor and model — Apple (iPhone, iPad, Mac), Samsung, Huawei, Google Pixel, OnePlus, and more where the UA string contains model info.
- Bot / crawler flag — identifies Googlebot, Bingbot, Baiduspider, YandexBot, social-media scrapers, and automation tools such as Puppeteer, Playwright, and Selenium.
Where to Find User-Agent Strings
You can obtain UA strings from several sources depending on your use case:
- Browser DevTools — open the Network tab (F12), select any request, and look for
User-Agentin the request headers. - Browser Console — run
navigator.userAgentin the Console tab to get your current browser's UA string. - Server access logs — web servers like nginx and Apache log the UA string for every request. Look for the quoted string near the end of each log line.
- Application logs — frameworks typically expose the UA via
request.headers['user-agent'](Node.js) orrequest.META['HTTP_USER_AGENT'](Django).
Common Use Cases
Developers and security engineers use UA parsing to serve responsive content to different device types, to tailor feature support based on the detected browser, to filter bot traffic from analytics, and to audit requests during security reviews. DevOps teams analyse UA strings in CDN and load-balancer logs to understand the client landscape without instrumenting frontend code.
Privacy and Security Notes
All parsing is performed entirely in your browser. No User-Agent string you enter is transmitted to any server. UA strings can contain sensitive context — for example, revealing that a user is on an unpatched OS version — so handling them locally avoids unnecessary data exposure. Note that UA strings can be spoofed: any client can send any string it likes, so UA-based access control should never be the sole security mechanism.