Find Companies Using jsDelivr: Technographic API Guide

jsDelivr is one of the most widely used free public CDNs on the web. It serves open-source files directly from the npm registry and GitHub repositories, which means a developer can drop a single <script> tag into a page and pull in Bootstrap, Chart.js, a jQuery plugin, or almost any published package without hosting a thing themselves. That convenience is exactly what makes “uses jsDelivr” an interesting technographic signal: it tells you something about how a team builds and ships front-end code.

This guide explains what jsDelivr usage actually reveals about a company, why it is detected differently from an infrastructure CDN like Cloudflare, and how to turn a raw domain list into a jsDelivr-confirmed lead list with the DetectZeStack API—starting with a single curl command you can run right now.

Why Find Companies Using jsDelivr?

Technographic data—what technology a company runs—is frequently a stronger qualifier than firmographics alone. A confirmed jsDelivr reference is a small but specific window into a team's front-end habits:

• They lean on public CDNs for dependencies. Loading libraries from cdn.jsdelivr.net rather than bundling and self-hosting them is a deliberate choice. It often signals a leaner build setup—static sites, server-rendered pages, or templates where pulling a script tag is faster than running a bundler.
• It usually comes bundled with the library it delivers. jsDelivr rarely travels alone. The same page that references it is almost always loading a detectable library—Bootstrap, Chart.js, a charting or carousel plugin—so one detection often hands you the front-end stack as well.
• It hints at a security and supply-chain posture. Teams that pull live third-party scripts from a public CDN have a different dependency surface than teams that vendor everything. For security tooling, SCA, or subresource-integrity products, that distinction is the qualifier.

The same pipeline applies to any detectable technology. We have companion guides for finding companies using Node.js and the broader topic of detecting a site's CDN and hosting provider—the filter changes, the workflow stays the same.

What jsDelivr Tells You About a Tech Stack

jsDelivr is a library-delivery CDN. It exists to serve versioned, open-source assets—a specific build of Bootstrap, a pinned release of Chart.js, a Vue component—straight from npm or GitHub. A company does not put its own domain behind jsDelivr; it references jsDelivr from inside its pages to fetch other people's code.

That has a direct consequence for what a detection means. Finding jsDelivr on a site does not tell you who hosts the site or how its traffic is proxied. It tells you the page intentionally pulls at least one third-party asset from a public CDN, and it points you at which asset when that asset is itself fingerprintable.

jsDelivr vs Self-Hosted Libraries and Other CDNs

It is worth being precise about where jsDelivr sits, because “CDN” is an overloaded word. There are two very different things both called CDNs:

An infrastructure CDN proxies the whole site, so it shows up in the site's DNS, headers, and certificate—the layer covered in how to detect a website's CDN and hosting provider. jsDelivr leaves none of those marks, because it never touches the site's own domain. It appears only as a reference inside the served HTML, alongside its peers cdnjs (cdnjs.cloudflare.com), unpkg (unpkg.com), and Google Hosted Libraries (ajax.googleapis.com).

The flip side is the self-hosted case. A team that runs a bundler and ships its libraries from its own domain will load, say, Bootstrap from /static/js/bootstrap.min.js—no jsDelivr reference at all. The library is still detectable on its own fingerprint, but the delivery signal is absent. In other words: a missing jsDelivr detection does not mean the site avoids Bootstrap; it means the site does not fetch Bootstrap from jsDelivr. Keep that distinction in mind when you read negatives.

How DetectZeStack Detects jsDelivr

Because jsDelivr lives in the page body, detection is a body-fingerprint match, not a DNS or header lookup. When DetectZeStack fetches a page, it scans the HTML for script and link references to cdn.jsdelivr.net. A match returns jsDelivr under the CDN category, at confidence 100, with source: "http"—because the evidence came directly from the HTTP response body.

You can spot the same raw signal yourself with a single command:

$ curl -s https://example.com | grep -o "cdn\.jsdelivr\.net" | head -1
cdn.jsdelivr.net

One match is enough to confirm the page references jsDelivr. The value the API adds is what comes with it: many of the libraries delivered over jsDelivr have their own fingerprints, so a single scan typically returns jsDelivr plus whatever it is delivering. A page that loads Chart.js from a cdn.jsdelivr.net path, for example, comes back with both jsDelivr (under CDN) and Chart.js as separate entries—often with a version parsed straight from the URL.

API Example: Detecting jsDelivr With a Single Call

You can try detection right now against the public demo endpoint—no API key required. The demo is IP-rate-limited, so use it for spot checks rather than bulk scans:

$ curl -s "https://detectzestack.com/demo?url=example.com" \
  | jq '.technologies[] | select(.name == "jsDelivr")'
{
  "name": "jsDelivr",
  "categories": ["CDN"],
  "confidence": 100,
  "description": "JSDelivr is a free public CDN for open-source projects. It can serve web files directly from the npm registry and GitHub repositories without any configuration.",
  "website": "https://www.jsdelivr.com/",
  "icon": "jsdelivr-icon.svg",
  "source": "http",
  "version": "",
  "cpe": ""
}

jsDelivr is matched directly off the cdn.jsdelivr.net reference in the page and categorized under CDN. It carries source: "http" because the evidence came from the HTTP response body, and the version field is empty—jsDelivr itself is a delivery network, not a versioned library, so there is nothing to read a version from. The libraries it delivers are where versions show up.

When you want the full stack for a domain rather than a filtered slice, call /analyze with your API key. The complete response is shaped like this:

$ curl -s "https://detectzestack.p.rapidapi.com/analyze?url=example.com" \
  -H "X-RapidAPI-Key: YOUR_KEY" \
  -H "X-RapidAPI-Host: detectzestack.p.rapidapi.com"
{
  "url": "https://example.com",
  "domain": "example.com",
  "technologies": [
    {
      "name": "jsDelivr",
      "categories": ["CDN"],
      "confidence": 100,
      "description": "JSDelivr is a free public CDN for open-source projects. It can serve web files directly from the npm registry and GitHub repositories without any configuration.",
      "website": "https://www.jsdelivr.com/",
      "icon": "jsdelivr-icon.svg",
      "source": "http",
      "version": "",
      "cpe": ""
    },
    {
      "name": "Chart.js",
      "categories": ["JavaScript graphics"],
      "confidence": 100,
      "description": "Chart.js is a free, open-source JavaScript library for data visualization.",
      "website": "https://www.chartjs.org",
      "icon": "Chart.js.svg",
      "source": "http",
      "version": "4.4.1",
      "cpe": ""
    }
  ],
  "categories": {
    "CDN": ["jsDelivr"],
    "JavaScript graphics": ["Chart.js"]
  },
  "meta": { "status_code": 200, "tech_count": 2, "scan_depth": "full" },
  "cached": false,
  "response_ms": 1842
}

Two entries from one page: jsDelivr as the delivery method and Chart.js as the thing being delivered, with its version parsed from the script URL. The top-level categories map groups every detection so you can pull all CDNs with .categories["CDN"] without iterating the array. The meta object carries the HTTP status_code, the tech_count, and the scan_depth; response_ms and cached sit at the top level.

One field to watch for list building is meta.scan_depth. A value of "full" means the HTTP fetch succeeded and body detection ran. A value of "partial" means the site blocked or timed out the HTTP request and only DNS and TLS layers completed—and since jsDelivr lives in the body, an absent jsDelivr entry on a "partial" scan tells you nothing. Those domains belong in a retry queue, not your rejects file.

Building a List of Companies Using jsDelivr at Scale

For list building, POST /analyze/batch accepts up to 10 URLs per request and analyzes them concurrently. Each entry in the response carries either a full analysis result or an error for domains that could not be fetched:

$ curl -s -X POST "https://detectzestack.p.rapidapi.com/analyze/batch" \
  -H "X-RapidAPI-Key: YOUR_KEY" \
  -H "X-RapidAPI-Host: detectzestack.p.rapidapi.com" \
  -H "Content-Type: application/json" \
  -d '{"urls": ["example.com", "getbootstrap.com", "wordpress.org"]}'

The response wraps one result object per URL, each with the same shape as a single /analyze response:

{
  "results": [
    { "url": "example.com",       "result": { "...full analysis..." : "" } },
    { "url": "getbootstrap.com",   "result": { "...full analysis..." : "" } },
    { "url": "wordpress.org",      "result": { "...full analysis..." : "" } }
  ],
  "total_ms": 2341,
  "successful": 3,
  "failed": 0
}

Because each result matches the single-domain shape, the filtering logic is identical whether you scan one domain or a thousand. Here is a complete, copy-pasteable pipeline using nothing but bash, curl, and jq. It reads domains.txt (one domain per line), sends batches of 10 to /analyze/batch, and appends every domain where jsDelivr is detected to jsdelivr_leads.csv, recording the tech count alongside it:

#!/usr/bin/env bash
# find-jsdelivr.sh — filter a domain list down to jsDelivr-confirmed leads
KEY="YOUR_KEY"
HOST="detectzestack.p.rapidapi.com"

echo "domain,tech_count" > jsdelivr_leads.csv

# Process domains.txt in batches of 10 (the /analyze/batch maximum)
xargs -n 10 < domains.txt | while read -r batch; do
  urls=$(printf '%s\n' $batch | jq -R . | jq -s '{urls: .}')
  curl -s -X POST "https://$HOST/analyze/batch" \
    -H "X-RapidAPI-Key: $KEY" \
    -H "X-RapidAPI-Host: $HOST" \
    -H "Content-Type: application/json" \
    -d "$urls" |
  jq -r '.results[]
    | select(.result != null)
    | .result as $r
    | select([$r.technologies[].name] | index("jsDelivr"))
    | [$r.domain, ($r.meta.tech_count | tostring)]
    | @csv' >> jsdelivr_leads.csv
done

wc -l jsdelivr_leads.csv

A 1,000-domain list becomes 100 batch calls. The index("jsDelivr") guard keeps a domain whenever jsDelivr appears in its technology list, and select(.result != null) skips domains that failed to resolve (those come back with an error field instead of a result). For a deeper treatment of batch throughput, retries, and a production Python scanner, see how to batch scan 1,000 websites.

If you want to segment by the library jsDelivr is delivering rather than just the delivery method, widen the filter to capture the co-detected technologies—the same technologies array already carries Chart.js, Bootstrap, jQuery, and whatever else the page pulls in. Our guides on detecting jQuery and the broader JavaScript framework detection cover those fingerprints in detail.

Use Cases: Sales, Competitive Intelligence, and Security

A jsDelivr-confirmed list is rarely the end goal on its own—it is the entry point to a more specific segment. Three common ways teams use it:

• Sales and prospecting. Pair the jsDelivr flag with the library it delivers. A list of sites pulling a specific charting or UI library from jsDelivr is a precise audience if you sell a competing or complementary front-end product. The delivery method narrows the list; the delivered library qualifies it.
• Competitive intelligence. Scanning a market segment for public-CDN usage tells you how teams in that space build. A cohort that leans heavily on jsDelivr and cdnjs is shipping differently than one that bundles and self-hosts everything—useful context when you are studying how an entire market makes front-end decisions.
• Security and supply-chain mapping. Every live third-party script is part of a site's dependency surface. Security teams use technographic scans to inventory which external CDNs a domain pulls executable code from, which feeds subresource-integrity audits and third-party-risk reviews. The CDN category is exactly the layer they need to enumerate.

Two practical enrichment moves once the list is built: cross-reference the infrastructure CDN to separate “loads libraries from jsDelivr” from “proxied through Cloudflare”—they are independent signals and a site commonly has both—and score by meta.tech_count, a rough proxy for how built-out a company's front end is. Feeding those signals into a scoring model is covered in our lead enrichment pipeline guide.

Get Started With the DetectZeStack API

The free tier includes 100 requests per month with no credit card—enough to validate the pipeline on a sample of your prospect list before scaling up. Sign-up is instant through RapidAPI:

1. Get a key at rapidapi.com/mlugoapx/api/detectzestack.
2. Spot-check a domain you know: curl -s "https://detectzestack.com/demo?url=yourdomain.com" | jq '.technologies[].name'
3. Run the batch script above against your first 100 domains.

Conclusion

Finding companies using jsDelivr comes down to reading one thing well: a cdn.jsdelivr.net reference in the page HTML. Because jsDelivr is a library-delivery CDN rather than an infrastructure one, it is detected from the body, not from DNS or headers—and the real prize is usually the library it carries, which a single scan returns alongside it. A single /analyze call answers the one-domain question; /analyze/batch turns a raw domain list into a jsDelivr-confirmed lead list; and meta.scan_depth tells you which negatives are real and which are unknowns worth a retry. Swap the jq filter and the same pipeline segments by infrastructure CDN, front-end library, or backend runtime instead.