Download websites that use Glide.js

About Glide.js

Carousel libraries are plumbing. Nobody writes a project brief demanding that a site have a slider, and yet as of September 2026 we detect Glide.js on 147,841 sites, which happens because sliders arrive bundled inside something else.

Released under MIT in 2014, the library is a dependency-free JavaScript slider with a modular build, and its appeal to the people who ship it is size. Theme authors, page-builder vendors and agencies pick one small library, then carry it into every project they produce for years afterwards. A component nobody requests by name ends up on a population this large through distribution rather than through demand.

The version field is where the entry becomes interesting. We can tell 25 distinct versions apart across the sites we see, with 3.6.0 the one encountered most. A spread that wide is not what a self-updating package looks like. Rather, it is what happens when a file is copied into a theme, shipped, and then never touched again, because the site owner never installed the library and has no idea it is present. Front-end dependencies distributed this way age in place, and the age of any given copy is set by the release date of the theme around it, not by anything the site has done since.

Geography follows the theme market rather than any regional preference. 93,503 of the sites resolve to United States and .com carries most of the domains, roughly the way the commercial template and page-builder economy distributes in general. The people who care about this field are not usually looking for carousel users. What they are looking for is evidence of a supply chain.

Two questions get answered with a list like this. The first is dependency risk. If a version of a widely bundled library turns out to carry a flaw, the affected sites cannot self-report, because most owners do not know the library is there, and a version-filtered population is the only practical way to size the exposure. The second question is market research on the layer above, since a library's distribution is a fingerprint of the themes and builders that ship it, and clustering the sites by co-installed technology tends to reconstruct which product bundles which dependency.

The detection caveat is real. Minified copies that have been renamed or merged into a single concatenated file can escape identification, and a build step that folds the library into an application bundle leaves nothing recognisable, so the count is conservative. Version reads depend on whatever identifier survives minification, which is why some sites are counted with no version attached.

Checking one domain tells you what a single site ships. The export tells you how a dependency spread across the web, which releases are still out there and where they sit, and no amount of per-domain lookups will assemble that picture for you.