Feature Detection vs Browser Sniffing
Use feature detection rather than user-agent sniffing.
Feature Detection vs Browser Sniffing is a free HTML Academy lesson on CoddyKit — lesson 2 of 4. You can read the complete lesson below for free — then practise it hands-on in the browser with a built-in code editor and a 24/7 AI tutor. It is part of the HTML Academy learning path, one of 4 lessons in the course, and your progress syncs across the web and the CoddyKit app.
Two Approaches to Compatibility
To know whether the current browser supports a feature, you can either detect the feature directly ("IntersectionObserver" in window) or sniff the user agent string (navigator.userAgent.includes("Chrome")). One is reliable; the other is a long-running source of bugs.
Why Sniffing Fails
User agent strings lie. Edge claims to be Chrome (and Safari and Firefox). Chrome on Android emits a different UA than Chrome on iOS. Browsers respect "freezing" of the UA string for privacy. Any logic based on UA strings breaks every few months.
Feature Detection Pattern
Check the actual API the code needs: if ("IntersectionObserver" in window) { ... }. If the property exists, the browser supports it; if not, take the fallback path. The check is direct, fast, and future-proof.
if ("IntersectionObserver" in window) {
const observer = new IntersectionObserver(handler);
} else {
loadPolyfill().then(() => { /* use IntersectionObserver */ });
}Detect, Then Use
Pair the detection with a real fallback. Detecting a missing feature is only useful if you have something to do when it is missing — load a polyfill, render a static alternative, or hide the feature entirely.
CSS Feature Queries
CSS has its own feature detection: @supports (display: grid) { ... }. The block applies only when the browser understands the property/value pair. Use it to ship grid layouts with float-based fallbacks for ancient browsers.
@supports (display: grid) {
.grid { display: grid; gap: 16px; }
}
@supports not (display: grid) {
.grid > * { float: left; width: 33%; }
}User Agent Client Hints
Modern browsers expose structured information via navigator.userAgentData (Chromium only). It returns brand+version pairs instead of a freeform string. Still prefer feature detection — UA hints are useful only when capability cannot be inferred from a property check.
When Sniffing is Acceptable
The narrow valid use case for UA detection is opting out of buggy browsers: a known iOS Safari bug in version X. Even then, prefer feature-based opt-outs (CSS.supports("aspect-ratio: 1")). UA detection should be a last resort.
Modernizr-style Libraries
Modernizr packages many feature detections and exposes them as classes on the <html> element (html.flexbox, html.no-flexbox). Modern projects rarely need it — most detections are a one-liner — but it remains useful for legacy migrations.
Testing the Fallback
Once detection is in place, test both paths. Open DevTools, override the feature to undefined, and verify the fallback works. Untested fallbacks rot — when the time comes for a user to need them, they often fail in ways the developer never imagined.
Detection in Frameworks
React, Vue and others have no special detection API — use plain JavaScript inside an effect or component initialization. Server-rendered apps must detect on the client because "IntersectionObserver" in window is undefined during SSR.
Avoid Capability-Based UA Sniffing
Some teams check the UA to guess capability ("Is this an iPhone? Then probably has Touch"). This conflates two unrelated things. Detect touch directly via "ontouchstart" in window or, better, prefer pointer events that abstract over input modality.
Knowledge Check
Why is feature detection preferred over user agent sniffing for handling browser capabilities?
Summary
Prefer feature detection ("API" in window) over user agent sniffing. CSS has @supports for the same purpose. Always pair detection with a real fallback and test both paths. UA sniffing should be reserved for opting out of known-buggy browser versions, never for guessing capabilities.
Frequently asked questions
Is the “Feature Detection vs Browser Sniffing” lesson free?
Yes — the full text of “Feature Detection vs Browser Sniffing” is free to read here on the web, and the HTML Academy course includes 4 lessons in total. To practise it interactively (a built-in code editor and a 24/7 AI tutor) and unlock the rest of the HTML Academy course, upgrade to CoddyKit PRO.
What will I learn in “Feature Detection vs Browser Sniffing”?
Use feature detection rather than user-agent sniffing. You practise HTML Academy with hands-on code you run directly in the browser, and a 24/7 AI tutor answers your questions as you work through the lesson.
Do I need any experience to start HTML Academy?
No prior experience is required. HTML Academy on CoddyKit is structured for beginners through advanced learners; this is — lesson 2 of 4, so you can start here or from the beginning and move at your own pace.
How long does the “Feature Detection vs Browser Sniffing” lesson take?
Most CoddyKit lessons take about 5–10 minutes. Each one is bite-sized and interactive, so you make steady progress and pick up exactly where you left off across the web and the app.
Can I write and run code in this HTML Academy lesson?
Yes. Every HTML Academy lesson includes a built-in code editor, so you write and run real code right in your browser and get instant AI feedback — no local setup required.
All lessons in this course
- The PE Philosophy Start with HTML
- Feature Detection vs Browser Sniffing
- Graceful Degradation vs Progressive Enhancement
- Building a PE Accordion