Download websites that use Modernizr

About Modernizr

The version column is where the record for Modernizr turns strange, and the strangeness is worth explaining before anything else. We hold 889 distinct version values, far more than the project has ever released, because the library is normally consumed as a custom build. A developer picks the feature tests a project actually needs, the builder stamps the output with an identifier for that combination, and the identifier is what ends up in the page. The string recorded as 2 is a fingerprint of one such build rather than a release number, which means counting distinct values measures how varied the builds are and not how many upgrades happened.

The library itself answers a question that has largely stopped being asked. Released in 2009 under the MIT license, it tests the browser for individual capabilities so a page can adapt to what is genuinely supported instead of guessing from a user agent string. In an era when browsers disagreed with each other about nearly everything, feature detection was the responsible way to build. Browsers then converged. The technique survives in narrow cases, but a front end that still loads a general-purpose detection library is usually a front end assembled while the technique was standard practice.

As of October 2026 we still find it on 2,414,568 sites, filed under JavaScript libraries, with United States accounting for 847,905 and .com carrying a large share of the volume. Distribution like that follows the theme and template ecosystems of the period rather than any current preference among developers, which is the same reason the version strings sit frozen where a builder left them.

Presence is therefore a dating tool, and dating tools have buyers. Agencies selling rebuilds want sites whose front end predates the current generation of frameworks, because those are the projects where a rebuild is an easy argument. Security and compliance teams want the same population for a different reason, since a page nobody has rebuilt in years tends to carry other unmaintained dependencies alongside this one, and a detection library is a cheap way to find that cohort without auditing every script on every page. Vendors of newer tooling read the list as a displacement target.

None of that reasoning works one domain at a time. A lookup confirms that a single site loads a detection library and then stops. The downloadable list lets you take the whole cohort, group it by country and domain suffix, join it against the other technologies recorded for the same hosts, and finish with a defensible statement about how much of a market is still serving front-end code from a particular era. The join is the point. A technology column on its own is trivia, and the same column crossed against geography, platform, and co-installed software is an argument.

The caveats matter and both push the count downward or sideways. Custom builds are frequently bundled into a site's main script file, where the identifying comment is stripped and the library becomes invisible to an external crawler, so the real footprint is larger than the figure we publish. Detection also cannot distinguish a deliberate modern use from an inherited fragment nobody has removed, and in practice the second case is common. Used as a marker of front-end age the record is dependable. Used as a measure of who actively depends on feature detection today it would overstate intent, since most of these installs are inheritance rather than choice.