User agents vs feature detection
Feature detection checks at runtime whether a specific capability (an API, a CSS feature) is available, rather than inferring it from the user-agent string. It is more reliable than user-agent sniffing because it tests the actual environment instead of a self-reported, spoofable label. The user agent still has narrow, legitimate uses, but capability decisions should rest on feature detection.
What this means
User-agent sniffing reads the user-agent string and assumes capabilities from the browser name and version it claims. Feature detection instead asks the environment directly — for example, whether a specific JavaScript API or CSS property exists — and acts on the answer.
The difference matters because user agents are self-reported and frequently inaccurate: they are spoofed, frozen by UA reduction, and shared across many engines via Chromium. The presence of an API is a fact about the running browser; the user-agent name is only a claim.
Why feature detection wins
Feature detection stays correct as the landscape shifts. A new browser version, a forked engine, or a spoofed string does not break a test that checks for the actual feature. UA sniffing, by contrast, must be updated for every new browser and is fooled by anything that lies about its identity.
It also degrades gracefully: detect the feature, use it when present, and provide a fallback when absent. CSS and standard web APIs offer built-in mechanisms for this kind of conditional support, which is more durable than a version table.
- Tests the real environment, not a self-reported label
- Survives new versions, forked engines, UA reduction, and spoofing
- Encourages graceful fallbacks instead of hard version gates
Where the user agent still fits
User-agent data remains reasonable for coarse analytics (browser-family mix), for serving a known workaround to a specific buggy engine, and for bot-vs-human classification where you are reading the client type, not probing a capability. These are narrow, defensible uses.
For anything that decides whether a feature will work, prefer feature detection or Client Hints. Reserve the user agent for context, and never make a capability assumption from a name and version alone.
How it appears in analytics and logs
If code branches on the user agent to decide whether a feature works, it is guessing. Feature detection branches on the real presence of the capability, which stays correct as browsers change and as user agents are reduced or spoofed.
Diagnostic use case
Decide whether a browser supports a feature without parsing the user agent, and understand the narrow cases where user-agent data is still appropriate.
What WebmasterID can help detect
Understanding this distinction clarifies why WebmasterID treats the user agent as coarse context, not as a capability oracle — feature support is a property of the runtime, not of a parsed string.
Common mistakes
- Gating a feature on a parsed browser version instead of detecting the feature.
- Maintaining a UA version table that breaks with every new browser release.
- Assuming a spoofed or reduced user agent reflects true capabilities.
Privacy and accuracy notes
Feature detection inspects capabilities, not identity, and avoids leaning on high-entropy user-agent detail. WebmasterID favours coarse signals and does not fingerprint via capability probing.
Frequently asked questions
- Should I ever use the user agent instead of feature detection?
- For deciding whether a capability works, prefer feature detection. The user agent is still reasonable for coarse analytics, targeting a known engine-specific bug, or bot-vs-human classification — uses that read client type rather than probe capabilities.
Related pages
- 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.
- Sec-CH-UA-Platform and Sec-CH-UA-Mobile
Sec-CH-UA-Platform and Sec-CH-UA-Mobile are User-Agent Client Hint request headers. Platform reports the operating-system family (such as Windows, macOS, or Android) and Mobile is a boolean for whether the client is a mobile device. Both are low-entropy hints sent by default in supporting Chromium browsers, offering coarse context without parsing the legacy user agent.
- User-agent reduction explained
User-agent reduction is Chrome's effort to freeze and trim the legacy user-agent string, removing fine-grained OS and full-version detail. The information is not gone; it moves to opt-in User-Agent Client Hints. This page explains what reduction changed and how detection should migrate to Client Hints.
- WebmasterID docs
How coarse user-agent context is used without capability guessing.
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.