User Agent Parser

The User-Agent header is one of the oldest pieces of metadata on the web, and it shows. Every HTTP client — your browser, Googlebot, the curl process running in a CI job, the Slack server building a link unfurl preview, the iPhone in your pocket — sends a string that is meant to identify what kind of software is making the request. The format was never formally standardized in any way that withstood real-world use, so over thirty years it has accumulated a layer of mythology: every browser pretends to be Mozilla because Netscape did, every WebKit-based browser pretends to be Safari for compatibility reasons, every Edge install pretends to be Chrome for the same reason, and every Chromium fork claims compatibility with three or four browsers it has nothing to do with. Parsing one of these strings reliably is harder than it looks, and parsing it correctly across the full set of clients hitting a real production site is harder still.

This parser is built for the reality of UA strings in 2026, which means it has to handle three distinct populations: human-driven browsers, search and AI crawlers, and scripted clients. The browser side is the easiest in theory and the trickiest in practice. Chrome, Firefox, Safari, Edge, Opera, Brave, Vivaldi, Samsung Internet, UC Browser and Yandex Browser all share enough lineage that their UA strings overlap in subtle ways, and the order in which you check patterns matters: every Chromium-based browser ships with both a Chrome/ token and its own brand token, so you must check the brand token first, otherwise an Edge UA gets misidentified as Chrome and a Brave UA gets misidentified as something generic. The parser checks brand tokens (Edg, OPR, Vivaldi, Brave, SamsungBrowser) before falling through to Chrome and Safari, which is the only ordering that produces correct results across the full population.

Engine detection is a separate concern from browser detection because they answer different questions. The engine tells you what rendering and JavaScript behavior to expect: Blink (Chrome, Edge, Opera, most others), WebKit (Safari, all iOS browsers), Gecko (Firefox), Trident (legacy IE). For feature-flag rollouts, A/B tests targeting platform behaviors, and rendering bug investigations, engine identity matters more than browser identity. The parser distinguishes the two correctly: a UA with both AppleWebKit/ and Chrome/ is Blink (Chrome's fork of WebKit), while a UA with AppleWebKit/ but no Chrome/ is real WebKit. This distinction matters most on iOS, where every browser — including Chrome and Firefox — is forced to use WebKit by Apple's policy, so the user installed Chrome but the rendering behavior is Safari's.

Operating system detection has its own quirks. Windows uses NT version numbers in the UA — Windows 10 and 11 both report NT 10.0, which means the UA cannot distinguish between them and the parser cannot either; you would need User-Agent Client Hints with the Sec-CH-UA-Platform-Version header for that, which most browsers do not yet send to most servers. macOS reports a version like 10_15_7 (with underscores) for backwards compatibility, even on macOS 14 / 15 — Apple stopped incrementing the major version after Catalina because old code matched 10.x exactly. The parser converts underscores to dots so the version reads naturally. Android version detection is straightforward; iOS detection requires looking at iPhone, iPad or iPod combined with the OS version inside the UA. Linux detection is permissive on purpose because there is no canonical Linux UA — distributions and browsers report it inconsistently.

Device detection is where most parsers oversimplify and produce wrong answers. The mobile/desktop/tablet question cannot be answered reliably from a UA alone in many cases. Android tablets sometimes ship a UA without the Mobile/ token, sometimes with it, depending on the vendor and the rendering mode the browser is in. iPad UAs since iPadOS 13 changed to look like macOS UAs, which is why pre-2020 device detection libraries reported iPads as desktop Macs — the parser handles this by checking for explicit iPad markers and treating ambiguous cases as desktop, which matches what most layout engines do anyway. Device vendor and model are extracted from the Android UA when present (between the Android version and the Build marker), which is the only reliable place that information appears.

Bot and crawler detection is where this tool earns its keep for SEO and analytics use cases. The bot pattern set covers the obvious ones — Googlebot, Bingbot, Yandex, Baidu, DuckDuckGo, Applebot — and the rapidly growing population of AI crawlers that have appeared since 2022: GPTBot (OpenAI), ChatGPT-User (live ChatGPT browsing), CCBot (Common Crawl, used by many LLMs), ClaudeBot/anthropic-ai (Anthropic), PerplexityBot, Bytespider (TikTok/ByteDance), and Google-Extended (Google's separate AI training crawler). For sites considering a robots.txt strategy specifically for AI training, identifying these bots cleanly is the prerequisite. The parser also covers SEO crawlers (AhrefsBot, SemrushBot, MJ12bot), social link previewers (FacebookExternalHit, Twitterbot, LinkedInBot, Slackbot, Discordbot, TelegramBot, WhatsApp), and headless automation frameworks (HeadlessChrome, Puppeteer, Playwright, PhantomJS).

A common question is why HTTP libraries like curl, wget, python-requests, Go-http-client, and Java HttpClient are flagged as bots. The reason is that for almost every server-side decision — rate limiting, abuse detection, A/B test segmentation, content negotiation — you want to treat scripted clients like bots, even when they are not literally crawlers. A python-requests UA is by definition not a real user, and treating it as one (caching its responses against a real user's session, charging it for ad impressions, counting it in analytics) leads to wrong numbers. The parser flags these clients explicitly so you can apply the same allow-list / deny-list logic to them as to crawlers.

User-Agent Client Hints (UA-CH) are the future Google has been promising since 2020, and they remain partially deployed. The idea is to split the UA string into structured headers — Sec-CH-UA, Sec-CH-UA-Platform, Sec-CH-UA-Mobile, etc. — that the server can request explicitly via Accept-CH. In practice, Chrome has been freezing the legacy UA string in stages since 2022 (the User-Agent Reduction project), so for Chromium-based browsers you may see slightly less detail than you used to (a frozen minor version, a frozen platform version, no full OS version). The parser handles the frozen UAs correctly — they look like normal Chrome UAs with conservative version numbers — but if you need true platform detail in 2026, you should be using UA-CH on the server side, not parsing UA strings. This tool is the right choice for ad-hoc inspection and for the long tail of clients that have not adopted UA-CH yet.

Privacy is a real concern when you log UA strings at scale. The UA string itself is not personal data in most jurisdictions, but combined with an IP address, the time of request, and the referer, it forms a fingerprint that can identify a small number of users with high confidence. GDPR, CCPA and similar regulations treat that combined identifier as personal data subject to retention limits and deletion requests. The relevant best practice is to log only the parsed fields you actually need (browser family, OS family, device type) rather than the full UA, and to rotate or hash IP addresses. This parser runs entirely in your browser, so the strings you paste here are never logged anywhere, but the underlying lesson applies to your production code.

The most common use cases for this tool divide into four buckets. First, debugging: a customer reports a bug with a screenshot but does not know what browser they are on; you ask them to open about:version or paste their UA from a known UA-display URL, then drop it here. Second, log forensics: an alert fires from a CDN log line with a suspicious UA; you paste it here to see whether it is a known crawler or something to investigate. Third, A/B test setup: a designer wants the new layout only on mobile Safari and current Chrome; the parser tells you exactly which UAs match each rule. Fourth, robots.txt strategy: you want to block all AI training crawlers; the parser shows you the AI bot fingerprints to add to your robots.txt or to your firewall.

Two implementation notes for engineers. First, never parse UA strings on the hot path of a request handler — parsers are regex-heavy and can be a measurable percentage of CPU on a busy server. Cache the parsed result keyed by the raw UA string, with a long TTL since UAs are extremely repetitive across requests from the same client. Second, treat parser output as best-effort — if you make a security or billing decision based on it, an attacker can trivially spoof any UA they want. Use UA parsing for analytics, content optimization, and rate-limit segmentation; do not use it as a security primitive.

This tool pairs well with the other Omnvert developer utilities. The Hash Generator is useful when you want to fingerprint UAs into a stable identifier for log aggregation. The Regex Tester is the right place to prototype custom UA patterns before bringing them back here for validation. The JSON Viewer is the right place to inspect the parsed-result JSON when you want to feed it into another tool. And the JWT Tool is a related concern when your backend includes UA-derived claims in session tokens — though, again, do not trust UA-derived claims for anything security-critical. All of these run in the browser with the same privacy guarantees, so an entire UA-handling workflow can happen in a single tab without a single request to a third-party service.