Accept-Language vs user agent
Accept-Language and User-Agent are different HTTP headers that answer different questions. Accept-Language expresses the visitor's preferred languages and locales; User-Agent identifies the client software and platform. Mixing them up leads to wrong localisation and brittle detection. Both are client-supplied claims and can be absent or altered.
Two headers, two jobs
The User-Agent header identifies the client software: browser, engine, version, and platform. The Accept-Language header lists the human languages the client prefers, with quality weights (q-values) expressing priority, for example a primary language followed by fallbacks.
Use Accept-Language to choose which translation of a page to serve. Use User-Agent (or better, Client Hints) for browser- or device-specific behaviour. Each header is the authoritative source for its own job and a poor proxy for the other.
Why not infer one from the other
A user agent does not reliably reveal language. A Chrome on Windows user agent could belong to a speaker of any language; the platform token is not a locale. Equally, Accept-Language says nothing about the browser or device.
Guessing language from the user agent, or device from Accept-Language, produces wrong results for travellers, multilingual users, and anyone who has configured their browser language independently of their region. Read the header that actually carries the information you need.
- User-Agent: client software, engine, version, platform
- Accept-Language: preferred languages with q-value priorities
- Neither header reliably substitutes for the other
Both are claims and can be missing
Like all request headers, both are supplied by the client and can be spoofed, reduced, or omitted. Many API clients, scripts, and bots send neither, or send a default User-Agent and no Accept-Language at all.
Serve a sensible default when Accept-Language is absent, and never use a missing or unusual user agent as the sole basis for access control. Combine signals rather than trusting any single header.
How it appears in analytics and logs
Accept-Language tells you what languages a client prefers, in priority order; User-Agent tells you the browser, engine, and platform. Neither is a reliable source for the other, and both can be missing on non-browser clients.
Diagnostic use case
Decide which content to serve (language vs device/browser logic) by reading the correct header, and avoid inferring language from the user agent or device from Accept-Language.
What WebmasterID can help detect
WebmasterID reads these headers as coarse context only — language preference and client family — without combining them into a fingerprint, so localisation and bot/human signals stay separate and privacy-safe.
Common mistakes
- Inferring a visitor's language from the User-Agent platform token.
- Inferring browser or device from Accept-Language.
- Assuming Accept-Language is always present — many non-browser clients omit it.
Privacy and accuracy notes
Both headers are coarse, client-supplied hints. Accept-Language is a language preference, not an identity; the user agent is software, not a person. WebmasterID treats both as low-resolution context and never as fingerprints or exact location.
Frequently asked questions
- Should I redirect users by language using the user agent?
- No. Use the Accept-Language header (and explicit user choice) for language. The user agent identifies software, not language, and using it for localisation produces wrong results.
Related pages
- User-Agent Client Hints
User-Agent Client Hints are HTTP headers (the Sec-CH-UA family) that let a site request specific browser, platform, and version detail rather than reading it all from one passive string. They underpin UA reduction: the raw user agent is shrinking, and finer detail moves to opt-in hints. This page explains the model.
- How to parse user agents safely
Parsing user agents by hand with regular expressions is fragile and breaks as strings evolve. The safer approach is to use a maintained UA library, store a coarse category rather than each visitor's raw string, and treat the result as a hint, not an identity. This page sets out a privacy-safe parsing approach.
- User agent sniffing pitfalls
User-agent sniffing means changing site behaviour based on substrings in the User-Agent header. It is fragile: it misfires on new or unexpected browsers, breaks as user agents are reduced, and is easily defeated by spoofing. Feature detection and Client Hints are more robust approaches for most cases.
- Privacy-first analytics
Coarse, header-level context without fingerprinting visitors.
Sources and verification notes
Last reviewed 2026-06-24. Facts are checked against primary/official sources where available; uncertain specifics are marked “Data not yet verified” rather than guessed.