Understanding and Parsing User-Agent Strings

What Are User-Agent Strings and Why Do They Matter?

Every HTTP request sent by a browser, app, or connected device includes a User-Agent header — a text string that identifies the software making the request. This string typically contains the browser name and version, the operating system, the rendering engine, and sometimes the device model. It was originally designed so that web servers could tailor their responses to different browsers, but it has evolved into a critical signal across the advertising ecosystem.

In ad tech, User-Agent strings drive decisions at every stage of the ad delivery pipeline. Demand-side platforms use them to target campaigns by device type, operating system, or browser. Supply-side platforms report device breakdowns to publishers. Ad servers select creative formats based on device capabilities — serving a lightweight MRAID ad to mobile, an HTML5 banner to desktop, or a VAST video tag to a connected TV. Analytics platforms rely on User-Agent parsing to segment traffic, detect bots, and attribute conversions to the correct device.

When User-Agent parsing goes wrong, the downstream effects are significant. Misclassifying a mobile device as desktop can serve the wrong creative, skew reporting metrics, and waste campaign budget on impressions that render incorrectly. Understanding how to read, parse, and troubleshoot User-Agent strings is therefore a core skill for anyone working in ad operations, QA, or ad tech engineering.

Anatomy of a User-Agent String

A typical User-Agent string looks like a confusing jumble of product tokens, version numbers, and platform identifiers. However, it follows a loose structure that becomes readable once you know the pattern. Consider this example:

The Mozilla Compatibility Token

Nearly every modern User-Agent string begins with Mozilla/5.0. This is a historical artifact from the early browser wars when servers would only send advanced content to "Mozilla-compatible" browsers. Today it carries no useful information — it is simply a legacy prefix that all browsers include for compatibility. You can safely ignore it during manual analysis.

The Platform and OS Section

The parenthesized section after the Mozilla token contains the operating system and platform details. In the example above, (Linux; Android 13; Pixel 7) tells us the device runs Android 13 on a Pixel 7. For desktop browsers, you would see entries like (Windows NT 10.0; Win64; x64) or (Macintosh; Intel Mac OS X 10_15_7). This section is the most reliable source of OS information in the UA string.

The Rendering Engine

Following the platform section, the rendering engine token identifies the layout engine used to render web content. AppleWebKit/537.36 indicates the WebKit-based engine used by Chrome, Safari, Edge, and most modern browsers. Firefox uses Gecko instead. The (KHTML, like Gecko) compatibility string is another historical artifact that persists for legacy reasons.

The Browser Identifier

The browser name and version usually appear near the end of the string. Chrome/120.0.6099.43 identifies the browser and its precise version. The Mobile token indicates that this is a mobile browser rather than a desktop one. Finally, Safari/537.36 appears because Chrome includes it for compatibility — another example of UA strings accumulating legacy tokens over the decades.

Using the User Agent Parser Tool

The User Agent parser extracts structured data from raw UA strings in a single step. Paste a User-Agent string into the input field, and the tool immediately displays a breakdown of the browser name and version, operating system and version, device type classification, and rendering engine.

The tool's output includes a device class label — Desktop, Mobile, Tablet, Connected TV, or Bot — based on the combination of signals in the UA string. This classification mirrors the logic that ad servers and DSPs use to make targeting decisions, so you can verify whether a specific UA would be classified correctly in your ad stack.

For deeper investigation, the tool provides a structured JSON representation of all parsed fields. This is useful when you need to file a bug report, document a device-specific issue, or feed the parsed data into another system. The JSON output includes raw values as well as normalized labels, so you can see both what the UA string literally says and how the parser interprets it.

Device Classification in Ad Tech

Accurate device classification is essential for ad targeting, creative selection, and reporting. The major categories used across the industry are desktop, mobile, tablet, connected TV (CTV), and bot. Each category has distinct characteristics in User-Agent strings.

Desktop

Desktop User-Agents identify themselves through OS tokens like Windows NT, Macintosh, or X11 (Linux). The absence of a Mobile token combined with a desktop OS is the primary signal. Desktop traffic typically supports the widest range of creative formats and the largest display sizes.

Mobile and Tablet

Mobile devices include the Mobile token and often list the device model (e.g., iPhone, Pixel 7). Tablets are trickier — iPads running iPadOS 13 and later report themselves as Macintosh by default, making them indistinguishable from Mac desktops in the UA string alone. Android tablets typically omit the Mobile token while keeping the Android platform identifier. This ambiguity is one of the strongest arguments for supplementing UA parsing with User-Agent Client Hints.

Connected TV (CTV)

CTV devices — smart TVs, streaming sticks, and set-top boxes — have the most varied User-Agent strings. Roku, Fire TV, Apple TV, Samsung Tizen, LG webOS, and gaming consoles each use proprietary UA formats with custom tokens. There is no universal "CTV" marker. Identifying CTV traffic requires maintaining a list of known CTV UA patterns and matching against it, which is why specialized parsing tools are valuable.

Bot Detection

Bots and crawlers typically identify themselves with tokens like Googlebot, bingbot, or AdsBot. However, malicious bots often spoof legitimate browser UA strings to avoid detection. Detecting sophisticated bot traffic requires looking beyond the UA string to behavioral signals, but the UA string remains a useful first-pass filter for known crawlers and well-behaved bots.

The Shift to User-Agent Client Hints (UA-CH)

Google's Chromium project has been gradually reducing the information in the User-Agent string — a process known as User-Agent reduction or "freezing." The goal is to reduce passive fingerprinting by limiting the amount of identifying information exposed in every HTTP request. Instead, websites that need detailed device information must actively request it through User-Agent Client Hints (UA-CH).

UA-CH works through a set of HTTP request headers that the server can request by sending an Accept-CH response header. The client then provides the requested hints in subsequent requests. Available hints include Sec-CH-UA (brand and version), Sec-CH-UA-Platform (operating system), Sec-CH-UA-Mobile (mobile flag), Sec-CH-UA-Model (device model), and Sec-CH-UA-Full-Version-List (complete version strings).

For ad tech, this shift has significant implications. The reduced UA string still contains enough information for basic browser and OS identification, but detailed version numbers and device models are no longer available without explicit Client Hints requests. Ad servers and analytics platforms that rely on passive UA parsing need to implement Client Hints support to maintain the same level of device intelligence. During the transition period, you will encounter both full and reduced UA strings in the wild, and your parsing logic needs to handle both gracefully.

Common Parsing Challenges

User-Agent Spoofing

Any client can set the User-Agent header to any value. Browser extensions, privacy tools, and developer settings allow users to change their UA string. Fraudulent traffic deliberately spoofs UA strings to appear as legitimate user traffic. While you cannot prevent spoofing, awareness of its prevalence helps you interpret analytics data with appropriate skepticism and layer additional detection methods (JavaScript API checks, behavioral analysis) on top of UA parsing.

WebView User-Agents

In-app browsers (WebViews) present unique parsing challenges. They often embed the host app's name and version in the UA string alongside the standard browser tokens. A Facebook in-app browser on iOS, for example, includes FBAN/FBIOS tokens in addition to the Safari rendering engine identifiers. Correctly identifying WebView traffic matters because WebViews may have different capabilities, cookie behavior, and ad rendering characteristics compared to standalone browsers.

Frozen and Reduced Strings

As Chrome's UA reduction rolls out, you will see User-Agent strings where the OS version is frozen to a generic value (e.g., Windows NT 10.0 even on Windows 11) and the browser version shows only the major number. If your parsing logic depends on exact version matching, it will need to be updated to work with these reduced strings. The User Agent parser tool handles frozen strings by flagging when the UA appears to be reduced and suggesting Client Hints as the alternative data source.

Practical Uses for QA and Analytics

In day-to-day ad operations, User-Agent parsing serves several practical purposes. During QA testing, checking the UA string confirms that the test environment matches the target device profile. If a creative is supposed to render on an iPhone 14 running Safari 17 but the UA string shows a desktop Chrome instance, the test results are invalid.

When investigating delivery discrepancies, the UA string from ad server logs reveals whether traffic is coming from the expected device mix. A campaign targeted to mobile that shows significant desktop UA strings in the logs indicates a targeting misconfiguration or fraudulent traffic.

For analytics and reporting, UA parsing provides the device, browser, and OS breakdowns that advertisers expect in campaign reports. Maintaining parsing accuracy across the transition to Client Hints ensures that these reports remain reliable and actionable for media planning decisions.

Integrating the User Agent parser into your daily workflow — checking UA strings from logs, tickets, and bug reports — builds the pattern recognition that makes device-related issues easier to diagnose. Over time, you develop an intuition for which UA tokens matter and which are legacy noise, making you faster and more effective at troubleshooting device-specific ad delivery problems.