Home / Find Sites Using a JavaScript Library
Use case
Find Sites Using a JavaScript Library
Most JavaScript libraries leave an unmistakable trace in page source: a CDN URL, a versioned filename, or an inline snippet that initializes a global. Search that trace and you have the library's real, current install base across the indexed web, who ships it, at which versions, from which CDNs. That answers adoption questions, powers dependency audits, and finds sites still running old or vulnerable builds.
Example footprints
jquery.min.js, jQuery, by its canonical filenamereact-dom, React's renderer, visible in CDN paths and unminified referencescdn.jsdelivr.net/unpkg.com, anything loaded from the big public CDNs (jsDelivr, UNPKG); add/npm/<package>@to pin one package, version visible
A worked example
The filename jquery.min.js appears in the homepage source of 34,960,796 domains, about 27% of the ~129M-domain August 2026 index. A raw count that size is rarely the goal, though; the interesting queries are narrower. Pin a major version with the regex jquery-1\.[0-9.]+\.min\.js to list sites still shipping jQuery 1.x, years out of support, or search a versioned CDN path like cdn.jsdelivr.net/npm/vue@2 to find installs of one line of releases. Every result opens to the full source, so the exact <script> tag and its version are right there.
Step by step
- Pick the footprint. The library's canonical filename or CDN path; the more version-specific, the cleaner the result set.
- Search it as an exact string, or switch to regex to match a version range.
- Verify. Open a few results, a real install is a
<script src=…>or inline snippet, not a mention of the filename in article text. - Narrow. Add a TLD filter or a second footprint with AND to intersect stacks.
- Export the domain list as CSV for your audit or outreach list.
False positives and gaps
Overcounting is modest and easy to spot: documentation pages and tutorials that mention a filename in text, and dns-prefetch/preconnect hints to a CDN the page never actually loads a script from. Undercounting is the bigger effect, modern bundlers compile libraries into hashed bundles like app.3f9c2e.js, erasing the filename entirely, so framework-style libraries are systematically less visible than their true adoption. Libraries installed via an inline snippet (analytics tools especially) stay visible: search the snippet's distinctive call, like mixpanel.init or _paq, instead of a filename. Treat every count as a floor, and verify in the full source before acting on a match.
Related fingerprints
Framework and library results in the directory: jQuery, React, Bootstrap, Alpine.js. For the query techniques, see regex search over source code and how source-code search works.
Search jQuery 1.x sites (regex) → Search jsDelivr libraries →
Frequently asked questions
Can I find sites on a specific version of a library?
Yes, when the version is visible in the source, a versioned filename (jquery-3.6.0.min.js), a CDN path with @version, or a ?ver= query string. A regex matches the whole range. Bundled builds hide version strings, so version searches undercount.
Why is React's count so much lower than its actual popularity?
Bundlers erase library filenames from production pages, so a source search measures visible references, not total usage. Server-rendered markers and CDN loads still match; hashed app bundles don't. Read framework counts as floors.
What's the best footprint for an npm package loaded from a CDN?
The CDN path with the package name, cdn.jsdelivr.net/npm/<package>@ or unpkg.com/<package>@, which pins exactly one package and usually exposes the version right in the URL.
Can I search for a global variable instead of a filename?
Yes, if the library is initialized by an inline snippet, that code is part of the page source. Strings like mixpanel.init or _paq are reliable footprints. A global that only exists at runtime inside a bundled file won't appear as a literal string.