Back to Glossary
U

User-Agent Header

The User-Agent header is a line of text that a client (such as a web browser, script, or bot) sends with an HTTP request to identify itself to the server.

In practical terms, it usually tells the server the browser family, rendering engine, operating system, and sometimes device details, enabling the server to make compatibility decisions or collect statistics.

Because HTTP is a text-based protocol, headers like User-Agent are simple name–value pairs. A typical request includes many headers (Host, Accept, Accept-Language, etc.); User-Agent is the one historically used for client identification. Despite its age, it’s still present in modern browsers—although privacy-minded changes are reducing its detail.

FYI: The header name is conventionally spelled exactly as User-Agent (capital U, hyphen, capital A). While HTTP header names are case-insensitive, this canonical form is widely used in documentation and tooling.

What does a User-Agent string look like?

A User-Agent string looks like a compact sentence of tokens, often separated by spaces and slashes, sometimes with semicolons inside parentheses.

Several compatibility tokens are historical artifacts: they persist so older sites that perform “UA sniffing” don’t break.

Examples (illustrative):

Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/124.0.0.0 Safari/537.36
Mozilla/5.0 (Linux; Android 14; Pixel 7) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/123.0.0.0 Mobile Safari/537.36
curl/8.6.0
Mozilla/5.0 (X11; Linux x86_64; rv:124.0) Gecko/20100101 Firefox/124.0
Mozilla/5.0 (Macintosh; Intel Mac OS X 14_4) AppleWebKit/605.1.15 (KHTML, like Gecko) Version/17.4 Safari/605.1.15

Notice the repeated “Mozilla/5.0” token. It’s a legacy compatibility prefix dating back to Netscape Navigator. Many sites once looked for “Mozilla” to decide whether a browser was “modern,” so other browsers copied it to avoid being blocked—this is UA spoofing for compatibility, not privacy.

Pro Tip: Never assume the User-Agent string is truthful. It’s easy to spoof in browsers, scripts, and proxies. Treat it as a hint, not an authoritative fact.

Example User-Agent strings by platform (illustrative)

These examples demonstrate typical shapes you’ll encounter. Versions are representative and may differ on your system.

Platform / ClientExample UA string (wrapped for readability)
Windows + ChromeMozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/124.0.0.0 Safari/537.36
macOS + SafariMozilla/5.0 (Macintosh; Intel Mac OS X 14_4) AppleWebKit/605.1.15 (KHTML, like Gecko) Version/17.4 Safari/605.1.15
Android + ChromeMozilla/5.0 (Linux; Android 14; Pixel 7) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/123.0.0.0 Mobile Safari/537.36
Linux + FirefoxMozilla/5.0 (X11; Linux x86_64; rv:124.0) Gecko/20100101 Firefox/124.0
CLI (curl)curl/8.6.0

What does each part of a User-Agent mean?

Each token in a User-Agent string conveys a hint about the client’s identity and environment.
While there’s no single enforced template across all clients, most browser UAs share a common shape:

  • Compatibility prefix: Mozilla/5.0
    Historical token signaling “modern” capabilities. It rarely reflects the actual browser brand today.
  • System comment block (in parentheses): e.g., (Windows NT 10.0; Win64; x64) or (Macintosh; Intel Mac OS X 14_4) or (Linux; Android 14; Pixel 7)
    Typically includes OS family and version; sometimes CPU architecture; on mobile, may include device model.
  • Layout/JS engine token: e.g., AppleWebKit/537.36, Gecko/20100101
    Indicates the rendering engine (WebKit, Gecko, Blink-derived tokens via AppleWebKit compatibility).
  • Compatibility phrase: KHTML, like Gecko
    A legacy string signaling compatibility with older engine expectations.
  • Browser brand and version: Chrome/124.0.0.0, Safari/605.1.15, Firefox/124.0, Version/17.4 (Safari)
    The surface brand and its version number.
  • Mobile indicator: Mobile (appears in many mobile UAs)
    Helps sites deliver touch-optimized layouts or smaller assets.
  • Command-line tools and libraries:
    Non-browser clients may use simple UAs like curl/8.6.0, Wget/1.21.4, or libraries such as python-requests/2.32.3.

FYI: The precise order and content vary by vendor and version. For example, Safari exposes its major features differently from Chrome, and Firefox keeps the Gecko identifier.

How is the User-Agent used?

Servers use the User-Agent to make compatibility decisions, gather analytics, optimize content delivery, and apply security policies. For step-by-step instructions on changing your User-Agent in Chrome for testing, see our guide: How to Change User-Agent in Google Chrome.

However, overreliance on UA parsing is brittle and can harm user privacy and accessibility.

Common uses:

  • Progressive enhancement and fallbacks: Serve polyfills or alternate CSS to older engines.
  • Bug workarounds: Ship targeted patches for a known browser version.
  • Content adaptation: Adjust UI for mobile vs. desktop; pick asset sizes.
  • Analytics and reporting: Measure browser/OS share across traffic.
  • Bot management: Heuristically distinguish “known good” bots (e.g., well-documented crawlers) from generic scrapers.
  • Access control and rate limits: Apply additional verification to suspicious or unsupported clients.
  • Compliance and monitoring: Track client diversity for QA and regulatory reporting.

Risks and caveats:

  • Spoofability: Anyone can forge a UA string.
  • Fragility: UA parsing breaks when vendors change format.
  • Privacy leakage: Detailed UA strings reveal OS and device details, increasing fingerprinting surface.
  • Exclusion by sniffing: Overstrict checks may lock out legitimate users.

Pro Tip: Prefer feature detection (e.g., checking for a JavaScript API) over rigid UA sniffing. Use the UA string only to inform decisions you cannot make reliably any other way.

What is the history of the User-Agent?

The User-Agent header originates from early HTTP, when servers needed a simple way to recognize clients and tailor responses.

As the web grew, vendors engaged in “UA string diplomacy,” adding compatibility tokens to appear modern to sniffing scripts, which led to today’s long, quirky strings.

Key historical points:

  • Early browsers: Netscape Navigator and others used “Mozilla” as a self-identifier. “Mozilla/4.0” became synonymous with “capable.”
  • Compatibility era: Competing browsers (including Internet Explorer) mimicked “Mozilla” so sites would serve them the same content.
  • Mobile rise: With smartphones, UAs began to include device and mobile indicators so servers could deliver responsive content before CSS and JS techniques were widespread.
  • Privacy and standardization: As concerns grew, browser makers moved toward reducing UA detail and offering User-Agent Client Hints (UA-CH) as a more controlled alternative.

FYI: The modern HTTP specifications still describe User-Agent, but contemporary browser roadmaps increasingly de-emphasize it in favor of privacy-preserving hints.

What does each part of a User-Agent record mean in practice?

Each part maps to a practical choice you might make in analytics, content, or security.
Below is a quick “meaning → typical action” mapping you can adapt:

  • OS family/version: Decide whether to ship a heavy WASM module, a GPU feature, or provide a lighter fallback.
  • Device class (Mobile/Desktop): Pick image sizes, enable touch affordances.
  • Engine (WebKit/Gecko/Blink): Choose CSS prefixes or JS shims for niche features.
  • Browser version: Apply a targeted workaround for a known rendering bug.
  • Architecture (x64/ARM): Tune binary downloads or native helpers (where applicable).
  • Bot identifiers: Allowlist major crawlers or throttle unknown scrapers.

Caution: Treat all of the above as heuristics, not truth. When security matters, verify using behavioral signals (e.g., JavaScript challenges), not just UA claims.