Modernizr

Libraries Visit modernizr.com

Modernizr is a JavaScript library that detects the features available in a user's browser.

33366 detections

20 websites tracked

Updated 15 Jun 2026

Websites Using Modernizr

What Is Modernizr?

Modernizr is a small, open-source JavaScript library that detects which HTML5 and CSS3 features a visitor's browser supports, then exposes that information so developers can adapt their pages accordingly. The direct answer to the most common question is that Modernizr is a feature-detection library: instead of guessing capabilities from the browser's name and version, it actually tests whether a given feature works and reports the result. Its signature behavior is adding CSS classes to the <html> element, one per detected feature, so that stylesheets and scripts can branch on real capabilities.

Modernizr rose to prominence during the HTML5 and CSS3 transition era, when browsers varied wildly in what they supported and developers needed a reliable way to provide graceful fallbacks. It is reported across the web to appear on a large number of sites, particularly older ones and those built on themes and frameworks that bundled it by default. Because precise usage figures vary by source and the library's relevance has declined as browsers converged on shared standards, the accurate framing is qualitative: Modernizr is a very widely encountered library on the existing web, especially on sites built during the early-to-mid 2010s, even though fewer new projects add it today. Treat any single hard percentage you see quoted in isolation with caution.

For technology profiling, detecting Modernizr is unusually easy and informative, because it deliberately writes visible CSS classes onto the page's root element. Those classes are a fingerprint you can read straight from the HTML. The presence of Modernizr also hints at a site's age and its concern with cross-browser compatibility and progressive enhancement.

How Modernizr Works

Modernizr's core idea is runtime feature detection. Rather than parsing the user agent string to infer what a browser can do, Modernizr runs tiny tests in the browser itself. For each feature, it attempts to use the relevant API or CSS property and observes whether it behaves as expected. The result is a boolean: supported or not.

The library performs two visible actions when it loads early in the page:

It rewrites the <html> class attribute. Modernizr removes a no-js class (commonly placed on the <html> element) and replaces it with js, confirming JavaScript is running. Then, for every feature it tests, it adds a class: the feature name if supported (for example flexbox, webgl, localstorage) or the feature name prefixed with no- if unsupported (for example no-touchevents, no-webp). The result is the distinctive long string of classes often called the Modernizr class soup.
It populates a global Modernizr object. Each tested feature becomes a property on window.Modernizr with a boolean value, so scripts can check Modernizr.flexbox directly rather than reading CSS classes.

This dual output is the whole point. Stylesheets can target .no-flexbox .layout to provide a float-based fallback only for browsers lacking flexbox, while JavaScript can write if (Modernizr.geolocation) { ... } to enable a feature conditionally. The pattern is the foundation of progressive enhancement: build for capable browsers, then provide sensible fallbacks for the rest.

A few mechanics matter for understanding and detecting Modernizr:

Custom builds. Modernizr is almost always used as a custom build that includes only the feature tests a project needs. The build tool produces a file commonly named modernizr-custom.js or a hashed variant. This keeps the library tiny.
Synchronous, early loading. Because the class swap should happen before the page renders to avoid a flash of unstyled fallback, Modernizr is typically loaded in the <head> and runs synchronously.
The no-js to js swap. Sites using Modernizr conventionally hardcode class="no-js" on the <html> element so that, if JavaScript is disabled, the no-js styles apply; when Modernizr runs, it flips this to js.
Optional add-ons. Older versions could include html5shiv (to make HTML5 elements styleable in legacy Internet Explorer) and a resource loader, though the loader was later deprecated.

Because its entire purpose is to annotate the page with capability classes, Modernizr is one of the most self-advertising libraries on the web, which makes detection straightforward.

How to Tell if a Website Uses Modernizr

Modernizr is among the easiest libraries to fingerprint precisely because it broadcasts its presence in the page markup.

Signals in the page and network

The <html> class soup. Open the page and look at the <html> element's class attribute. A long, space-separated list of feature names like js flexbox flexboxlegacy canvas canvastext webgl no-touchevents geolocation postmessage ... localstorage is the unmistakable Modernizr signature. The mix of plain feature names and no- prefixed names is the giveaway.
The js / no-js swap. Seeing class="no-js" in the raw source that becomes class="js ..." after load indicates Modernizr (or a similar progressive-enhancement pattern) is running.
CDN and script paths. Look for requests to modernizr.js, modernizr.min.js, or modernizr-custom.js, from hosts such as cdnjs.cloudflare.com/ajax/libs/modernizr or a local /js/ directory. The path or filename sometimes includes a version, for example modernizr/2.8.3/modernizr.min.js.
The global Modernizr object. Type window.Modernizr in the DevTools Console. Seeing an object whose properties are feature names with boolean values is a direct confirmation. Many builds also expose Modernizr._version.
Version markers. Where present, Modernizr._version returns the build's version string, and the script path may also carry a version.

Tools to confirm it

Tool	What you do	What it reveals
View Source	Open the page HTML source	`class="no-js"` on `<html>`, plus a `modernizr` script reference
DevTools Elements	Inspect the live `<html>` element	The feature class soup (`js flexbox no-touchevents ...`) after load
DevTools Console	Type `window.Modernizr` or `Modernizr._version`	The feature-boolean object and version string
DevTools Network	Filter by JS and reload	A request for `modernizr-custom.js` or `modernizr.min.js`
Wappalyzer	Run the browser extension on the page	Flags Modernizr in the JavaScript libraries category

Because the class soup appears directly in the rendered DOM, Modernizr is rarely ambiguous to detect, unlike bundled networking libraries. For a broader walkthrough of identifying client-side technologies, see our guides on how to check what JavaScript libraries a website uses and how to find out what technology a website uses.

Key Features

Modernizr does one job and does it thoroughly.

Feature detection, not browser sniffing. Tests real capabilities rather than inferring from the user agent.
CSS classes on <html>. Adds supported and no- prefixed classes for stylesheet branching.
JavaScript API. Exposes Modernizr.featureName booleans for conditional scripting.
no-js to js swap. Confirms JavaScript availability and enables no-script fallbacks.
Custom builds. Include only the tests you need, keeping the file tiny.
Hundreds of tests. Covers CSS features, HTML5 APIs, input types, media formats, and more.
Optional polyfills. Historically bundled html5shiv for legacy Internet Explorer support.

A few features deserve emphasis. The CSS class approach is what made Modernizr ubiquitous in theme and framework code: designers could write fallback styles without touching JavaScript, which fit naturally into stylesheet-driven workflows. The custom-build philosophy is also important for detection, because the resulting file is usually named modernizr-custom.js and contains only a subset of tests, so the exact class soup varies from site to site. And the feature-detection principle itself outlived the library's heyday: the idea of testing capabilities rather than sniffing browsers became a web development best practice, even on sites that no longer ship Modernizr.

Pros and Cons

Modernizr was essential during the browser-fragmentation era, but its value has shifted as browsers converged.

Pros

Reliable, capability-based detection instead of fragile user-agent sniffing.
Enables clean progressive enhancement through CSS classes and a JS API.
Tiny when built with only the needed tests.
Self-documenting: the class soup makes a site's capability assumptions visible.
Well-established pattern supported by many themes and frameworks.

Cons

Much less necessary today, since modern browsers broadly support the same features and CSS offers native @supports feature queries.
Adds a render-blocking script in the <head> if used the conventional way.
The class soup can bloat the <html> element and the page markup.
Maintenance and new feature tests have slowed as the library matured.
For most current projects, native @supports and standardized APIs cover the same ground without a dependency.

Modernizr vs Alternatives

Modernizr competes less with other libraries and more with native browser capabilities that have since matured. The right choice depends on which browsers you must support.

Approach	Type	Dependency	Best for
Modernizr	JS feature-detection library	Yes	Legacy support, JS-driven feature branching, existing themes
CSS `@supports`	Native CSS feature query	No	Modern CSS fallbacks without JavaScript
Native API checks	Inline JS (`if ('fetch' in window)`)	No	Targeted JS feature checks without a library
Polyfill services	Hosted polyfill delivery	External	Filling specific gaps in older browsers
User-agent sniffing	Parsing the UA string	Varies	Discouraged; brittle and easily spoofed

The most instructive comparison is Modernizr versus the native CSS @supports rule. When Modernizr was created, CSS had no built-in way to ask whether a property was supported, so adding classes to <html> was the only practical mechanism for capability-based styling. Today, @supports (display: grid) { ... } lets stylesheets branch on feature support with no JavaScript and no library at all. For JavaScript-side checks, simple inline tests like if ('geolocation' in navigator) cover most needs. As a result, new projects often skip Modernizr entirely, while it remains common on existing sites and in older theme code. If you encounter it, it usually signals a codebase built when cross-browser fragmentation was a daily concern.

For other client-side libraries you may find alongside Modernizr on older sites, see our profile of jQuery, which shipped together with Modernizr in many themes of the same era.

Use Cases

Modernizr appears in a recognizable set of scenarios, most of them rooted in cross-browser compatibility.

Progressive enhancement. Sites that provide fallbacks for browsers lacking flexbox, grid, or specific APIs.
Legacy browser support. Codebases that needed to support older Internet Explorer alongside modern browsers.
Theme and framework defaults. Many WordPress themes, HTML5 boilerplates, and front-end starter kits bundled Modernizr by default, so it appears even when the site owner did not choose it deliberately.
Conditional feature loading. JavaScript that enables advanced functionality only when Modernizr reports support, such as canvas, WebGL, or touch events.
Capability-based styling. Stylesheets that swap layouts or effects based on .flexbox versus .no-flexbox classes.

For competitive research and lead generation, spotting Modernizr is a useful age signal: it suggests a site or theme built during the HTML5 transition, which can inform how you assess a prospect's technical currency.

Frequently Asked Questions

Is Modernizr still needed in modern web development?

For most new projects, no. Modern browsers broadly support the same HTML5 and CSS3 features, and the native CSS @supports rule plus simple JavaScript checks like if ('fetch' in window) cover the feature-detection use cases Modernizr was built for, without adding a dependency. Modernizr remains valuable when you must support older browsers or when you are maintaining an existing codebase that already relies on its CSS classes. It is encountered far more often than it is newly adopted.

What is the class soup on the `<html>` element?

That long list of space-separated class names on <html>, such as js flexbox canvas no-touchevents geolocation localstorage, is Modernizr's output. For each feature it tests, Modernizr adds the feature name as a class when supported, or the same name prefixed with no- when unsupported. Stylesheets and scripts then branch on these classes to provide fallbacks. Seeing this pattern is the clearest possible sign that a site uses Modernizr.

How do I detect Modernizr on a website?

The fastest way is to inspect the <html> element in DevTools and look for the feature class soup, or open the Console and type window.Modernizr to see the feature-boolean object. You can also check the page source for a class="no-js" attribute that flips to js, and look in the Network tab for a modernizr-custom.js or modernizr.min.js request. Wappalyzer and BuiltWith will also flag it. Because Modernizr writes visible classes, it is one of the easiest libraries to confirm.

Why does Modernizr swap `no-js` for `js`?

Sites that use Modernizr conventionally hardcode class="no-js" on the <html> element. If JavaScript is disabled, that class stays and any no-js fallback styles apply. When Modernizr runs, it removes no-js and adds js, signaling that scripting is available so enhanced styles and behaviors can take over. This swap is a core part of the progressive-enhancement pattern Modernizr was designed to support.

Does Modernizr slow down my site?

Modernizr is small, especially when built with only the tests you need, but it is conventionally loaded synchronously in the <head> so the class swap happens before render. That makes it a render-blocking script, which can add a little latency. For modern sites that need only a few checks, replacing Modernizr with native @supports and inline API checks removes the dependency and the blocking request entirely.

Want to identify the JavaScript libraries, frameworks, and full stack behind any website instantly? Try StackOptic at https://stackoptic.com.

Alternatives to Modernizr

jQuery135459 sites Swiper46630 sites Slick Carousel41516 sites Fancybox34785 sites Owl Carousel32878 sites jQuery UI32414 sites Cookiebot30349 sites Lottie19766 sites Quantcast Choice18104 sites Facebook SDK17722 sites

Compare Modernizr

Modernizr vs jQuery→Modernizr vs Swiper→Modernizr vs Slick Carousel→Modernizr vs Fancybox→Modernizr vs Owl Carousel→

Analyze a Website

Check if any website uses Modernizr and discover its full technology stack.

Analyze Now