The jQuery.support object stores internal browser capability test results that jQuery uses when normalizing DOM and CSS behavior. This tutorial explains what it is, why it was deprecated in 1.9, what changed in 1.11+, and what to use instead when you need real feature detection in your own code.
01
Object
$.support
02
Since 1.3
Added
03
Deprecated
Since 1.9
04
Internal
Not public API
05
Lazy tests
Since 1.11
06
Modernizr
Use instead
Fundamentals
Introduction
Early web development required dozens of tiny browser-specific workarounds. jQuery centralised those checks in one place: the jQuery.support object. When you called $.css(), $.ajax(), or $.clone(), jQuery consulted support flags to decide which code path was safe on the current browser.
That design helped jQuery maintain one consistent API across IE, Firefox, Safari, and Opera. However, exposing those flags encouraged plugins and application code to depend on undocumented property names. When browsers fixed old bugs, jQuery removed obsolete flags — and external code broke.
Since jQuery 1.9, the official documentation marks jQuery.support as deprecated for external use. You should treat it as read-only curiosity when debugging legacy projects, not as a feature-detection toolkit for new features.
Concept
Understanding the jQuery.support Property
jQuery.support is a plain JavaScript object attached to the global jQuery namespace. Each property name describes a browser quirk or capability — historically things like whether the CSS opacity property worked reliably, whether <tbody> elements were auto-inserted in tables, or whether cloned nodes preserved event handlers.
The object is populated when jQuery loads (or lazily when a module first needs a test). Values are typically booleans, though since jQuery 1.11 some entries are functions that run the test on first call and cache the result. That keeps unused tests from slowing initial page load.
⚠️
Important for beginners
Do not write if ($.support.someFlag) in your application. jQuery may rename or delete properties between minor releases. Use Modernizr, native APIs, or progressive enhancement instead.
Foundation
📝 Syntax
Access the global support object — there are no parameters:
jQuery
jQuery.support
// or
$.support
Return value
An Object whose properties represent internal feature-test results.
Property names and meanings are not guaranteed — they change as jQuery internals evolve.
Since jQuery 1.11+, the object is not reliably JSON.stringify-able because some values are functions.
Read-only inspection pattern
jQuery
// Educational only — do not branch app logic on these keys
console.log(typeof $.support); // "object"
console.log(Object.keys($.support)); // current internal flags in this jQuery version
Cheat Sheet
⚡ Quick Reference
Topic
Detail
Added
jQuery 1.3
Deprecated (external use)
jQuery 1.9
Type
Global object property
Access
jQuery.support / $.support
Lazy tests
Some values are functions since 1.11+
JSON serializable
No (since 1.11 / 1.12)
Recommended for apps
No — use Modernizr or native detection
Compare
📋 $.support vs Modernizr vs Native APIs
Three approaches to feature detection — only two are safe for application code.
$.support
internal
Deprecated — jQuery only
Modernizr
public API
Stable class names on html
CSS.supports
native
CSS feature queries
in operator
"fetch" in window
Simple API checks
Hands-On
Examples Gallery
These examples inspectjQuery.support for learning — they do not recommend using it in production logic. Open DevTools or use the Try-it links with jQuery 3.7.1.
📚 Getting Started
Read-only inspection of the support object in current jQuery.
Example 1 — List Current Support Property Names
See which internal flags exist in the jQuery version you load — names differ across releases.
jQuery version: 3.7.1
support type: object
property count: (small set of internal flags)
keys: checkClone, clearCloneStyle, ...
How It Works
jQuery 3.x keeps only the flags its modules still need. Older tutorials listing $.support.opacity or $.support.boxModel describe jQuery 1.x — those properties were removed long ago.
📈 Practical Patterns
Understand value types, serialization limits, legacy code, and modern alternatives.
Example 2 — Boolean vs Function Properties
Since jQuery 1.11, some support entries are lazy test functions — call them like $.support.prop() inside jQuery, not in app code.
jQuery
Object.keys($.support).forEach(function (key) {
var val = $.support[key];
console.log(key + ": " + typeof val);
});
checkClone: boolean
clearCloneStyle: function
...(each key with typeof)
How It Works
Lazy functions defer expensive DOM measurements until jQuery actually needs them. That is why the official docs warn that jQuery.support is no longer JSON-serializable.
Example 3 — Why JSON.stringify($.support) Fails
Logging support to JSON for analytics or remote debugging does not work reliably.
JSON.stringify skips or mishandles function values. Never assume you can ship the whole support object to a server — log explicit, documented feature tests instead.
Example 4 — Legacy Plugin Pattern (Do Not Copy)
Old plugins sometimes branched on removed flags — this breaks on jQuery 1.9+.
jQuery
// ANTI-PATTERN — $.support.opacity was removed in jQuery 1.9
function setFade(el, opacity) {
if ($.support && $.support.opacity) {
$(el).css("opacity", opacity);
} else {
$(el).css("filter", "alpha(opacity=" + (opacity * 100) + ")");
}
}
// Modern: CSS opacity works everywhere jQuery 3 targets
console.log("opacity flag exists?", "opacity" in $.support); // false in 3.x
setFade("#box", 0.5); // .css("opacity") is fine
When upgrading legacy sites, search for $.support and replace with progressive enhancement or native checks. The jQuery Migrate plugin can restore some removed APIs temporarily while you refactor.
Example 5 — Modern Feature Detection Instead
Test the capability you actually need — not jQuery’s internal clone/style flags.
jQuery
var features = {
fetch: typeof fetch === "function",
flexbox: window.CSS && CSS.supports("display", "flex"),
localStorage: (function () {
try {
localStorage.setItem("_t", "1");
localStorage.removeItem("_t");
return true;
} catch (e) {
return false;
}
})()
};
console.log(features);
// Branch on features.fetch — not on $.support.ajax
This is what jQuery’s documentation recommends: detect features your UI needs with stable, documented APIs — or use Modernizr when you want a curated test suite and CSS class hooks on <html>.
Maintaining legacy plugins — find and remove $.support dependencies during upgrades.
Debugging Migrate warnings — plugins that still touch removed support flags.
Teaching browser history — see how libraries handled IE quirks before evergreen browsers.
Version comparison — diff Object.keys($.support) between jQuery 1.x and 3.x in DevTools.
Not for new features — always use explicit feature tests in greenfield code.
🧠 How jQuery Uses support Internally
1
Page loads jQuery
The core file defines jQuery.support as an empty or partially filled object.
Init
2
Module needs a test
When .css(), .clone(), or similar runs, jQuery checks the relevant flag.
Lazy
3
Run DOM micro-test
jQuery creates temporary elements, measures layout, or probes APIs — then caches the boolean.
Probe
4
✅
Pick code path
Internal jQuery code uses the result — your app should not mirror this pattern.
Important
📝 Notes
Added in jQuery 1.3; deprecated for external use in jQuery 1.9.
Official docs: properties may be removed when no longer needed internally.
Not JSON-serializable since jQuery 1.11 / 1.12 (function-valued entries).
Related removed API: jQuery.browser (user-agent sniffing, removed 1.9).
Use Modernizr or native feature detection for your project.
jQuery Migrate plugin can help legacy code during upgrades — not a long-term strategy.
Still present in jQuery 3.7.x — but with a much smaller, internal-only surface.
Compatibility
Browser Support
jQuery.support exists wherever jQuery runs — it is not a cross-browser API for your code. It was added in jQuery 1.3 and deprecated for external use in jQuery 1.9.
✓ Deprecated 1.9
jQuery jQuery.support
Still reachable in jQuery 1.x, 2.x, and 3.x for internal use. Do not build features on it — use Modernizr, CSS.supports(), or explicit in-window checks instead.
N/ANot for app code
Google ChromeAll versions · Desktop & Mobile
Full support
Mozilla FirefoxAll versions · Desktop & Mobile
Full support
Apple SafariAll versions · macOS & iOS
Full support
Microsoft EdgeAll versions · Chromium & Legacy
Full support
Internet ExplorerIE 6+ · Legacy environments
Full support
OperaAll modern versions
Full support
Public API stabilityUnstable
Bottom line: Treat jQuery.support as documentation of jQuery internals, not as a feature-detection library. Property names change between jQuery versions without semver guarantees for consumers.
Wrap Up
Conclusion
jQuery.support is a historical artifact of jQuery’s cross-browser normalization layer — a cache of internal capability tests that powered reliable DOM APIs in the IE era. It remains in modern jQuery builds, but only for jQuery’s own modules.
If you are learning jQuery today, remember the official guidance: inspect it to understand legacy code, but detect features in your application with Modernizr, native APIs, or progressive enhancement — never with undocumented $.support properties.
Use Modernizr or native CSS.supports() for CSS features
Test specific APIs: "fetch" in window
Search legacy codebases for $.support when upgrading jQuery
Read jQuery 1.9 upgrade guide when maintaining old plugins
Prefer progressive enhancement over browser sniffing
❌ Don’t
Branch application logic on $.support.* properties
Assume property names from jQuery 1.x tutorials still exist
Serialize $.support to JSON for logging
Confuse $.support with $.browser (removed)
Ship new code that depends on jQuery internals
Summary
Key Takeaways
Knowledge Unlocked
Five things to remember about jQuery.support
Internal flags — not your feature-detection toolkit.
5
Core concepts
🛠01
$.support
Object
API
1.902
Deprecated
External use
Warning
🔍03
Internal
jQuery only
Scope
fn04
Lazy
Since 1.11
Perf
M05
Modernizr
Use instead
Replace
❓ Frequently Asked Questions
jQuery.support is an object on the global jQuery namespace that caches results of internal browser capability tests. jQuery uses these flags to pick cross-browser code paths for DOM, CSS, and events. It was added in jQuery 1.3.
Yes. jQuery.support was deprecated in jQuery 1.9. The official docs state it is intended for jQuery's internal use only. Application code should not depend on its properties — they may be removed without notice to improve startup performance.
No — jQuery explicitly recommends against it. Use a dedicated library such as Modernizr, or native checks like CSS.supports(), 'fetch' in window, or element.canPlayType(). Those APIs are stable public contracts; jQuery.support properties are not.
Since jQuery 1.11 or 1.12, some support properties are lazy functions that run a test when called, not plain booleans. That deferred testing speeds page load. JSON.stringify cannot serialize functions, so logging the whole object to JSON fails or omits entries.
Yes — a trimmed set of internal flags remains in jQuery 3.7.x for jQuery's own modules. The object is still reachable as jQuery.support or $.support, but it is not a supported public API for developers.
Both were early jQuery browser-detection helpers. jQuery.browser (from navigator.userAgent) was removed in 1.9. jQuery.support tests features and bugs instead of parsing user-agent strings, but it was also deprecated in 1.9 for external use. jQuery Migrate can restore some removed APIs for legacy plugins.
Did you know?
Before jQuery.support, many developers used jQuery.browser, which parsed navigator.userAgent strings. User-agent sniffing breaks when browsers change their reported name — feature tests are more reliable. jQuery removed jQuery.browser in 1.9 the same release cycle that deprecated external use of jQuery.support, pushing the ecosystem toward capability detection instead of browser name matching.