How to Tell If a Website Uses jsDelivr

jsDelivr is one of the most widely used free public CDNs for delivering open-source assets — JavaScript libraries, CSS frameworks, fonts and more — straight from npm, GitHub and WordPress. Because it serves from its own well-known domain, detecting it is straightforward: open the Network tab and look for any asset loaded from cdn.jsdelivr.net. This guide covers every reliable signal, what the URL paths reveal, the look-alikes to rule out, and what jsDelivr usage tells you about the site.

What is jsDelivr?

jsDelivr is a free, open-source-focused public CDN that lets developers load third-party libraries and assets without self-hosting them. Instead of downloading jQuery, Bootstrap or a font and serving it from their own server, a developer can point a <script> or <link> tag at cdn.jsdelivr.net and let jsDelivr deliver the file from a fast, globally distributed, multi-CDN network (it combines several CDN providers for reliability). It can serve files published to npm, files directly from GitHub repositories, WordPress plugins and themes, and it can even combine and minify files on the fly. It is one of the "big three" public asset CDNs alongside Google Hosted Libraries and unpkg/cdnjs.

For detection, the key context is that jsDelivr is a delivery mechanism for open-source third-party assets, not a private origin CDN for the whole site. It sits alongside whatever hosting the site uses, handling libraries and fonts while the site's own pages and private files come from elsewhere. So finding jsDelivr tells you which open-source dependencies a developer chose to load from a public CDN — and, usefully, exactly which versions — but it does not reveal where the site itself is hosted. Its usage spans the entire web, from hobby projects to large platforms, because it is free and convenient.

How jsDelivr delivers assets

jsDelivr URLs follow a consistent structure whose path reveals the source. The most common is cdn.jsdelivr.net/npm/<package>@<version>/<file> for packages published to npm — for example cdn.jsdelivr.net/npm/[email protected]/dist/jquery.min.js. Files served straight from GitHub use /gh/<user>/<repo>@<version>/<file>, WordPress plugins and themes use /wp/<...>, and the /combine/ endpoint bundles multiple files into one request (e.g. /combine/npm/pkg1@1,npm/pkg2@2). The @<version> segment pins the exact version, which can be a precise number, a range, or latest.

Because the package name and version are right there in the URL, a jsDelivr request tells you a great deal: which library the site uses, exactly which version (handy for spotting outdated or vulnerable dependencies), and whether the developer pins versions or rides latest. Knowing this path structure — /npm/, /gh/, /wp/, /combine/ — makes both detection and dependency analysis easy. There is little to disguise here, since the whole point of jsDelivr is to load from its public domain.

How to tell if a website uses jsDelivr

Confirm at least one signal (a single asset URL suffices).

1. Check the Network tab. Filter for jsdelivr. Any script, stylesheet, font or image from cdn.jsdelivr.net confirms jsDelivr.

2. View the page source. Search the HTML for cdn.jsdelivr.net. <script> and <link> tags frequently reference it directly.

3. Read the path. The /npm/, /gh/, /wp/ or /combine/ path tells you the source and the specific package and version.

4. Note the versions. The @<version> in each URL reveals exactly which library versions the site loads — useful for a quick dependency audit.

5. Look for combine requests. A /combine/ URL indicates the developer bundles multiple open-source files through jsDelivr, a small sign of performance awareness.

What the jsDelivr signals look like

<script src="https://cdn.jsdelivr.net/npm/[email protected]/dist/jquery.min.js"></script>
<link href="https://cdn.jsdelivr.net/npm/[email protected]/dist/css/bootstrap.min.css" rel="stylesheet">
<script src="https://cdn.jsdelivr.net/gh/owner/[email protected]/plugin.min.js"></script>
GET https://cdn.jsdelivr.net/combine/npm/pkg1@1,npm/pkg2@2

Any cdn.jsdelivr.net asset URL is conclusive, and the path reveals the source and version.

jsDelivr versus other public CDNs — avoiding false positives

Match the host to keep public asset CDNs distinct. jsDelivr uses cdn.jsdelivr.net; unpkg uses unpkg.com; cdnjs uses cdnjs.cloudflare.com; Google Hosted Libraries uses ajax.googleapis.com. Each is a distinct public CDN, and a site may use several at once. The important conceptual distinction is between these public open-source asset CDNs and a site's private origin CDN (Cloudflare, Fastly, CloudFront): jsDelivr delivers third-party libraries, not the site's own pages, so its presence says nothing about where the site is hosted. Do not infer hosting from jsDelivr — instead, treat it as a window into the site's third-party dependencies and their versions.

How reliable is each jsDelivr signal?

A cdn.jsdelivr.net asset URL is definitive — there is no ambiguity, since the domain belongs solely to jsDelivr. The path reliably reveals the source (npm/GitHub/WordPress) and the exact version. The weakest "situation" is simply that jsDelivr usage is so common and so benign that it tells you less about the site's own infrastructure than an origin CDN would. There is essentially no false-positive risk for the detection itself; the interpretive caution is only to remember that jsDelivr is a public asset CDN, not the site's host. As a rule, a single cdn.jsdelivr.net request confirms it instantly.

What jsDelivr usage reveals about a site

Finding jsDelivr signals a developer who loads open-source libraries from a public CDN rather than self-hosting or bundling them — a common, pragmatic choice. More valuable than the mere presence is what the URLs reveal: the specific libraries and versions the site depends on. That makes jsDelivr a useful lens for dependency and security analysis — an outdated jQuery or a known-vulnerable library version pulled from jsDelivr is easy to spot in the path. For a security-minded auditor, public-CDN dependencies are also worth noting because they introduce a third-party trust relationship (mitigated by subresource integrity, if the site uses integrity attributes). If you sell security, performance or dependency-management tooling, the version information a jsDelivr scan surfaces is genuinely actionable.

What finding jsDelivr means for sales, agencies and competitive research

For sales and prospecting, jsDelivr itself is a weak qualifier (it is everywhere), but the library versions it exposes are valuable: outdated or vulnerable dependencies flag sites that need security or maintenance help, and the libraries in use hint at the site's technical approach.

For agencies and consultants, finding jsDelivr and reading the versions gives an instant, lightweight dependency audit — spotting old libraries, missing subresource-integrity attributes, or an over-reliance on latest that risks breakage. That is a concrete, demonstrable basis for a maintenance or security conversation.

For competitive and market research, the libraries a competitor loads from jsDelivr reveal part of their front-end approach and their attention to dependency hygiene, useful when benchmarking technical maturity.

jsDelivr in the wider stack

jsDelivr sits alongside, not instead of, the site's own hosting. You will find it on sites of every kind, delivering libraries while the pages themselves come from an origin server fronted by a CDN like Cloudflare or Fastly. On WordPress sites it may serve plugin or theme assets via /wp/; on hand-built sites it commonly delivers jQuery, Bootstrap, a charting library or fonts. The presence of integrity (subresource integrity) attributes on jsDelivr <script> tags is a small but telling sign of a security-conscious developer. For an auditor, the valuable details are which libraries and versions are loaded, whether they are current, whether SRI is used, and what other public CDNs accompany jsDelivr; together these characterise the site's third-party dependency footprint and its maintenance hygiene.

A quick jsDelivr confirmation walkthrough

Open the site with developer tools on the Network panel and reload, then filter for jsdelivr. Any asset from cdn.jsdelivr.net confirms it. Click a request and read the path: note the source (/npm/, /gh/, /wp/), the package name and the @version. Scan for several jsDelivr requests to build a quick picture of the site's open-source dependencies and whether any are outdated. View the source and search for cdn.jsdelivr.net in <script>/<link> tags, and check whether they carry integrity attributes. A single cdn.jsdelivr.net request is enough to confirm jsDelivr.

A quick jsDelivr detection checklist

• Filter the Network tab for jsdelivr; any cdn.jsdelivr.net asset is conclusive.
• Read the path source: /npm/, /gh/, /wp/ or /combine/.
• Note each library's @version for a quick dependency audit.
• Check for integrity (SRI) attributes on jsDelivr script tags.
• Remember jsDelivr is a public asset CDN, not the site's own host.
• Note which other public CDNs (unpkg, cdnjs, Google) accompany it.

Detecting jsDelivr at scale

Checking one site is quick, but auditing many — to find sites loading outdated or vulnerable libraries from public CDNs — calls for automation. StackOptic detects jsDelivr and thousands of other technologies from a real browser, surfacing the libraries and versions a site depends on. For related reading, see our guides to checking what JavaScript libraries a website uses and telling if a website uses Cloudflare or another CDN, and the full jsDelivr technology profile.