User Agent Parser & Analyzer

Instantly decode any User Agent string to reveal the browser, operating system, rendering engine, device type, CPU architecture, and bot status — all privately in your browser.

🔒 Everything runs locally in your browser. No data is sent to any server.

Ready to Analyze

Your browser UA will be auto-loaded on page start. Paste any UA string above or pick an example below to get started.

Common User Agent Examples

Click any row to instantly load that User Agent string into the analyzer.

Label User Agent String Load
Chrome 124 – Windows 11 Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/124.0.0.0 Safari/537.36 Use →
Firefox 125 – macOS Mozilla/5.0 (Macintosh; Intel Mac OS X 14.4; rv:125.0) Gecko/20100101 Firefox/125.0 Use →
Safari 17 – macOS Sonoma Mozilla/5.0 (Macintosh; Intel Mac OS X 14_4_1) AppleWebKit/605.1.15 (KHTML, like Gecko) Version/17.4.1 Safari/605.1.15 Use →
Edge 124 – Windows 10 Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/124.0.0.0 Safari/537.36 Edg/124.0.0.0 Use →
Mobile Safari – iPhone iOS 17 Mozilla/5.0 (iPhone; CPU iPhone OS 17_4_1 like Mac OS X) AppleWebKit/605.1.15 (KHTML, like Gecko) Version/17.4.1 Mobile/15E148 Safari/604.1 Use →
Chrome – Android (Samsung) Mozilla/5.0 (Linux; Android 14; SM-S928B) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/124.0.6367.82 Mobile Safari/537.36 Use →
iPad – iPadOS 17 Mozilla/5.0 (iPad; CPU OS 17_4_1 like Mac OS X) AppleWebKit/605.1.15 (KHTML, like Gecko) Version/17.4.1 Mobile/15E148 Safari/604.1 Use →
Googlebot 2.1 Mozilla/5.0 (compatible; Googlebot/2.1; +http://www.google.com/bot.html) Use →
Bingbot Mozilla/5.0 (compatible; bingbot/2.0; +http://www.bing.com/bingbot.htm) Use →
Internet Explorer 11 – Windows 7 Mozilla/5.0 (Windows NT 6.1; Trident/7.0; rv:11.0) like Gecko Use →
Opera – Windows Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/124.0.0.0 Safari/537.36 OPR/110.0.0.0 Use →
curl (CLI HTTP client) curl/8.6.0 Use →

How to Use the UA Parser

  1. Auto-detect — On page load, your browser's UA is loaded automatically for instant analysis.
  2. Paste custom UA — Paste any UA string from server logs, analytics, or documentation into the text area.
  3. Click Analyze — Hit the "Analyze" button or simply type to trigger real-time parsing.
  4. Read the dashboard — Eight labeled result cards display every detected property at a glance.
  5. Use examples — Click any row in the examples table to test common UA strings instantly.

What Gets Detected

  • Browser Chrome, Firefox, Safari, Edge, Opera, IE — with exact version number.
  • Engine Blink, Gecko, WebKit, Trident — the rendering core powering the browser.
  • OS Windows (with NT version mapped to marketing name), macOS, Linux, Android, iOS.
  • Device Desktop, Mobile, Tablet, or Bot/Crawler category.
  • CPU x64 (64-bit), x86 (32-bit), or ARM architecture.
  • Bot Named bot detection (Googlebot, Bingbot, curl, etc.).

Understanding User Agent Strings: Historical Evolution, Parsing Mechanics, and the Shift to Client Hints

The User-Agent (UA) header is one of the oldest and most fundamental components of HTTP communication, originally standardized in RFC 1945. Its original goal was simple: allow web clients (like browsers) to identify themselves to remote web servers so the server could optimize output formatting. However, over the past three decades, the structure of User Agent strings has evolved into a highly complex, historically bloated series of tokens that developers must audit and parse with extreme care.

The Historical bloat of UA Strings

To understand why a modern Google Chrome User Agent begins with "Mozilla/5.0" and references "Gecko" and "Safari", one must study the history of early web browsers. In the mid-1995s, Netscape (developer of the "Mozilla" codebase) introduced support for frames, a visual layout feature that rival browsers did not support. Webmasters configured their servers to return framed HTML only to browsers containing the "Mozilla" identifier. To bypass this, competitors began prepending "Mozilla/" to their user agents to ensure their users received the advanced layouts. This established a precedent of compatibility sniffing tokens that persists today, forcing modern engines to list legacy frameworks inside their identifiers.

Browser Rendering Engine Reference

A browser\'s rendering engine is the core engine responsible for compiling HTML, parsing CSS, and rendering visual outputs to the screen. Below is a historical breakdown of these engines:

Rendering Engine Key Browser Implementations Technical Origin / Fork History
Blink Google Chrome, Microsoft Edge, Opera, Brave, Vivaldi Forked from WebKit in 2013; optimized for Chromium\'s multi-process layout.
WebKit Apple Safari, All iOS web browsers Developed by Apple, originally derived from KDE\'s open-source KHTML engine in 2001.
Gecko Mozilla Firefox, Waterfox Developed by Netscape/Mozilla; built for extensible modular and standard-compliant layouts.

Parsing Mechanics and Crawler Detection Heuristics

Parsing User Agents relies on matching a sequence of specific regular expression tokens in a prioritized sequence. Because modern Chromium-based browsers include tokens for both Chrome and Safari in their strings, a parser that naively checks for "Safari" first will misidentify Google Chrome. The engine must evaluate more specific tokens (like "Edg/" or "OPR/") before moving to general browser tokens like "Chrome/" and fallback "Safari/" markers.

Similarly, detecting automated bots and crawlers requires matching the UA string against a database of known search engine patterns. Crawlers like Googlebot (Googlebot/2.1) and Bingbot (bingbot/2.0) declare their identity to comply with webmaster directives. Programmatic library requests like curl, Wget, or Python\'s requests are also parsed and categorized under the "Bot/Crawler" classification, providing webmasters with valuable traffic telemetry.

The Future: User Agent Reduction & Client Hints

To combat privacy violations arising from "browser fingerprinting"—where ad networks compile granular device version strings to construct unique visitor profiles without consent—browser vendors are actively implementing **User Agent Reduction**. This process freezes specific OS versions, device models, and browser build versions to generic values. Moving forward, the W3C recommends transitioning to **User-Agent Client Hints (UA-CH)**. Under this standard, servers request granular parameters (like operating system versions or exact chipsets) using specific request headers (e.g. Sec-CH-UA-Platform-Version), exposing sensitive data only when explicitly permitted.

Crawlable Code Examples

Before: Fragile Sniffing (Fails on Chrome/Edge)
// Bug: Returns true for Chrome and Edge too!
function isLegacySafari(userAgent) {
  return userAgent.indexOf("Safari") !== -1;
}
After: Robust Sequential Token Matching
// Prevents false positives by checking in priority
function parseSafari(userAgent) {
  const hasSafari = userAgent.includes("Safari");
  const hasChrome = userAgent.includes("Chrome");
  return hasSafari && !hasChrome;
}

Frequently Asked Questions

What is a User Agent string and what is its primary historical purpose?

A User Agent (UA) string is a standardized line of descriptive text sent by browsers and HTTP clients to web servers inside every request header. Originally introduced in RFC 1945 during the early web era, its primary purpose was to inform web servers of the specific browser name, rendering capability, and operating system in use. This allowed servers to dynamically optimize the returned HTML, CSS, and JavaScript payload, ensuring compatibility with primitive layouts, handling legacy browser limitations, and logging web visitor statistics.

Why do Chrome, Edge, and Safari User Agent strings include historical tokens like "Mozilla/5.0" and "Gecko"?

Modern User Agent strings contain a convoluted series of tokens like "Mozilla/5.0" and "like Gecko" due to a historical phenomenon known as user-agent sniffing. In the early days of the web, webmasters configured servers to only deliver advanced layout features to Netscape browsers (identified by "Mozilla"). To bypass this restriction and prevent their users from receiving dumbed-down pages, rival browsers began prepending "Mozilla/5.0" to their strings. Over time, this chain of compatibility tokens grew, meaning a modern Chrome User Agent lists "Mozilla", "AppleWebKit", "Chrome", "Safari", and "like Gecko" to guarantee older servers continue to deliver standard modern styles.

How does the browser rendering engine Blink differ from WebKit and Gecko?

Blink, WebKit, and Gecko are the three dominant web page rendering engines in active use today. Blink, developed by Google as part of the Chromium project, is a fork of WebKit optimized for multi-process sandboxed architectures and powers Chrome, Microsoft Edge, Opera, and Brave. WebKit is Apple's proprietary rendering engine, derived originally from KHTML, which powers Safari and, due to Apple iOS App Store rules, all browsers running on iPhone/iPad devices. Gecko is Mozilla's modular layout engine built specifically for Firefox, focusing on extensible open standards and memory safety.

What is User Agent reduction and freezing and why are browsers implementing it?

User Agent reduction and freezing is a privacy-focused initiative spearheaded by browser developers to combat cross-site "browser fingerprinting" tracking practices. Fingerprinting involves compiling minor details from standard request headers (like the precise OS patch version or device build number inside a UA string) to create a unique identifier for individuals without their consent. Under the new reduction rules, modern browsers freeze specific segments of their UA strings to static, generic values. Web developers are encouraged to transition to User-Agent Client Hints (UA-CH), which require explicit server-side permission flags to access sensitive device parameters.

How does a regex-based parser distinguish between human browsers and bot crawlers?

A client-side regex parser distinguishes crawlers from human traffic by matching the User Agent string against a robust database of known crawler signature patterns. Automated indexers, search engine bots, and scraper tools identify themselves by declaring tokens such as "Googlebot", "bingbot", "Baiduspider", or "facebookexternalhit". Additionally, HTTP requests generated by development libraries typically contain signature wrappers like "curl/", "Wget/", or "python-requests". The parser scans for these specific patterns and, if a match occurs, flags the device category as a bot while parsing the developer name.

Why should developers avoid relying solely on User Agent strings for security-sensitive checks?

User Agent strings must never be trusted for security-critical decisions or access control because they reside completely under the client's control. Any HTTP client, terminal console, or browser extension can freely modify or "spoof" its User Agent string to represent any desired platform (e.g., a simple curl scraper pretending to be Googlebot or Google Chrome). Relying solely on these strings leaves your applications vulnerable to parameter bypass attacks. Security checks must be implemented via backend validation gates, such as verifying the IP address domain name using reverse DNS lookups for official search bots.

Are my browser's User Agent string or any pasted strings sent to FlowStack servers for parsing?

No, absolutely not. All User Agent parsing, token categorization, regex evaluations, and icon mappings are executed 100% inside your browser's local sandboxed memory context. This tool leverages browser-native JavaScript and custom regular expressions to analyze the UA string in real-time. No network calls, analytical tracking scripts, or server requests are ever triggered to external backend servers. Your private data and server logs remain completely private to your local computer, making this utility highly secure for auditing corporate or production log variables.