Parse a User-Agent string into browser, OS, and device

This parser turns that line into a predictable result containing the browser name and version, operating system and version, and a practical device category. It uses transparent, deterministic pattern rules, so the same input always produces the same output without a network request, random behavior, fingerprinting, or hidden enrichment.

Provide the complete header whenever possible

Paste the value of the User-Agent HTTP header into the user_agent field, including all product tokens and the parenthesized platform section. Complete strings give the rules enough evidence to distinguish browsers that share a rendering lineage. For example, current Edge, Opera, Samsung Internet, and Chrome strings can all include a Chrome token, so the parser checks their more specific identifiers before accepting the generic Chrome match. The same ordering matters for Firefox and Chrome on iOS, where Apple platform requirements produce strings that differ from their desktop forms. Leading and trailing whitespace is ignored, but an empty or whitespace-only value is rejected as invalid input because there is nothing meaningful to classify. The parser does not contact the device, look up an IP address, inspect client hints, or combine the string with other identifiers. Supply the original header rather than a shortened label such as “Chrome on Windows” if you need versions. A shortened or unfamiliar string may still be accepted, but fields unsupported by recognizable evidence are returned as Unknown with a null version instead of being guessed.

Understand how browser and operating-system rules work

Detection follows a fixed precedence table built around commonly published User-Agent tokens. Browser-specific tokens such as Edg, OPR, SamsungBrowser, CriOS, and FxiOS are evaluated before broad Chrome, Firefox, and Safari patterns. This prevents a Chromium-based browser from being mislabeled merely because its header contains Chrome for compatibility. Safari uses its Version token because the separate Safari token describes the product family rather than the public browser release. Operating-system parsing similarly checks Windows Phone before desktop Windows, Android before generic Linux, and iOS before macOS-style compatibility fragments. Underscores in Apple version values are normalized to dots. Windows NT values are mapped to familiar releases where a dependable conventional mapping exists; Windows NT 10.0 is deliberately reported as “10 or 11” because the legacy header alone cannot reliably separate those releases. These are known-pattern rules, not probabilistic claims. New products, frozen compatibility strings, embedded web views, privacy-reduced headers, and vendor-specific forks can therefore produce Unknown or a broad family result until an identifying rule exists. That conservative behavior is safer for analytics and routing than inventing precision.

Use device type as a practical category, not an identity

The device_type result is a coarse operational category: desktop, mobile, tablet, bot, or unknown. Tablet indicators are evaluated before general mobile indicators because many Android tablets include Android while intentionally omitting Mobile. Recognized phones, iPhones, iPods, Windows Phone devices, and other mobile tokens return mobile. Well-known crawler terms return bot, which is useful for log summaries but should not replace layered abuse controls or verified crawler authentication. A recognizable desktop operating system or browser defaults to desktop; a string with no known browser or operating-system evidence returns unknown. These categories describe what the sender chose to advertise, not a verified physical device. User-Agent values can be modified, automated clients can imitate browsers, and modern privacy features intentionally reduce detail. Use the result for reporting, compatibility hints, log enrichment, or choosing a sensible default experience. Do not use it as a security boundary, a unique fingerprint, or proof that a visitor owns a particular device. When correctness affects access control, payments, or fraud decisions, combine server-side authorization and purpose-built risk signals rather than relying on this parsed header alone.