jsDelivr

jsdelivr.com · 3 records in Egress and tunnels, Storage · JSON

Records 3

★ qualifiesjsDelivr (npm + GitHub proxy CDN)
Storagefree tieridentity email?card?limit per-object-capevidence reportedstale on 2026-11-05
caveatjsDelivr as the free CDN layer over GitHub repos
Storagefree tieridentity email?card?limit per-object-capevidence reportedstale on 2026-11-05
fails: quotajsDelivr
Egress and tunnelsidentity anonymousno cardlimit per-object-capevidence reportedstale on 2026-11-06

jsDelivr (npm + GitHub proxy CDN)

Storage

www.jsdelivr.comRegistrystorage/jsdelivrJSON compare report an error

Free allowance: No storage quota of its own — it is a serving and permanence layer over npm and GitHub, so the quota is whatever the origin package holds.
Verdict: ★ qualifiesusable as stated; the read path was probed
Cost: free tier
Identity: email?placeholder, not evidence; card unknown, phone unknown
Binding limit: per-object-capsingle files >20 MB
Evidence: reported5 sources; a third party said so
Freshness: stale on 2026-11-05checked 2026-10-21 (inherited); stale on 2026-11-05

Free tier	No storage quota of its own — it is a serving and permanence layer over npm and GitHub, so the quota is whatever the origin package holds. Hard limits: packages >150 MB and (for GitHub) single files >20 MB are refused by default, raisable on request. unit MB; metered on stored-bytes
Price	none stated
Limits	per-object-cap (binding) single files >20 MB source 150 MB per npm package, 20 MB per single GitHub file (both default, raisable via GitHub issue). Rate limiting applies to purge, not to reads.
Identity	email (placeholder) not published
Egress	Fully free and explicitly unmetered.
Per-object cap	single files >20 MB (20000000 bytes)
Retention	\| Retention is stronger than the origin: 'Previously served immutable files may be retained in permanent storage even after upstream deletion
Interface	rest rest
Tooling	Plain GET on cdn.jsdelivr.net/npm/<pkg>@<ver>/<path> and /gh/<owner>/<repo>@<ref>/<path>. No client needed. Cache-purge API exists (email-gated).
Composes with	Chains onto npm (see npm candidate) or onto GitHub repos: publish the blob as an npm tarball, then serve it from jsDelivr at a URL with 1-year immutable cache and no bandwidth charge.
Reliability	Retention is stronger than the origin: 'Previously served immutable files may be retained in permanent storage even after upstream deletion. We do not accept removal requests simply because a package or version was unpublished, deleted upstream, or is no longer needed.' Once a URL has been fetched it keeps working after you delete the npm package — that is a genuine cold-archive property. Counter-risk: a 150 MB package cap means a naive >150 MB npm tarball 403s ('Package size exceeded the configured limit of 150 MB') even though npm itself accepted it.
Parsed numbers	has-free-tier 1 per-object-cap 20 MB

Evidence 5

date	source	what it proved
2026-10-21	www.jsdelivr.com/about	'no bandwidth limits or premium features and its completely free to use by anybody'
2026-10-21	github.com/jsdelivr/jsdelivr/blob/master/Terms%20of%20Use.md	'no limits on bandwidth or number of requests'; 'Previously served immutable files may be retained in permanent storage even after upstream deletion'
2026-10-21	github.com/jsdelivr/jsdelivr	(README) — 'Packages larger than 150 MB or single files larger than 20 MB (in the case of GitHub) are not supported by default'
2026-10-21	cdn.jsdelivr.net/npm/left-pad@1.3.0/package.json	probe: GET -> 200, Access-Control-Allow-Origin: *, Cache-Control: public, max-age=31536000, s-maxage=31536000, immutable, Server: cloudflare
2026-10-21	cdn.jsdelivr.net/npm/onnxruntime-node@1.20.1/bin/napi-v3/win	probe: GET -> 403, body 'Package size exceeded the configured limit of 150 MB.' (confirms the cap is real and enforced at fetch time)

Unknown values 2

per object cap notes: the field may be stated in a source that was not read
retention notes: the field may be stated in a source that was not read

jsDelivr as the free CDN layer over GitHub repos

Storage

www.jsdelivr.comPaaSstorage/jsdelivr-as-the-free-cdn-layer-over-github-reposJSON compare report an error

Free allowance: Free with no limits on bandwidth or number of requests; GitHub-proxy soft limits of 10 000 actively accessed files and 100 000 files per repository
Verdict: caveatusable, with a named limit or an unprobed read path
Cost: free tier
Identity: email?placeholder, not evidence; card unknown, phone unknown
Binding limit: per-object-capper file | 20 MB
Evidence: reported11 sources; a third party said so
Freshness: stale on 2026-11-05checked 2026-10-21 (inherited); stale on 2026-11-05

Free tier	free with no limits on bandwidth or number of requests; GitHub-proxy soft limits of 10 000 actively accessed files and 100 000 files per repository unit objects; metered on object-count; the file-count soft limits are not automatically enforced
Price	none stated
Limits	per-object-cap (binding) per file \| 20 MB source Git repo files only — release assets are NOT served (probed: /gh/cli/cli@v2.102.1/dist/README.md -> 404). ~20 MB effective per-file ceiling for the GitHub proxy (the git-unlimited-storage README states 'jsDelivr per file \| 20 MB'); hard per-file/per-package caps are undocumented and enforced at request time. Does not serve the >2 GiB release assets, so the serving path for big objects stays on GitHub's own Fastly edge.
Identity	email (placeholder) not published
Egress	Unmetered, and immutable-cached at the edge: probed 'Cache-Control: public, max-age=31536000, s-maxage=31536000, immutable' plus Access-Control-Allow-Origin: *.
Per-object cap	files up to 20 MB through the GitHub proxy, regardless of repository size (20000000 bytes)
Retention	\| Immutable: 'Previously served immutable files may be retained in permanent storage even after upstream deletion' — deletion upstream does not remove it from jsDelivr
Interface	rest rest
Tooling	URL pattern https://cdn.jsdelivr.net/gh/USER/REPO@TAG/path — no client needed, no auth, no config. Purge API exists for cache busting.
Composes with	Serving layer only: pair it with Releases (storage) or a git repo (small files). One repo backs 1 TiB/day because the edge absorbs repeats with a 1-year immutable TTL.
Reliability	Immutable: 'Previously served immutable files may be retained in permanent storage even after upstream deletion' — deletion upstream does not remove it from jsDelivr. Extension blocklist exists; binaries with unusual extensions can be refused.
Parsed numbers	has-free-tier 1 per-object-cap 20 MB

Evidence 11

date	source	what it proved
2026-10-21	www.jsdelivr.com/terms/acceptable-use-policy	'there are no limits on bandwidth or number of requests'; soft limit '100 000' files per repository
2026-10-21	source not published	probe: GET cdn.jsdelivr.net/gh/jquery/jquery@3.7.1/dist/jquery.min.js -> 200, Cache-Control: public, max-age=31536000, s-maxage=31536000, immutable, Access-Control-Allow-Origin: *
2026-10-21	source not published	probe: GET cdn.jsdelivr.net/gh/cli/cli@v2.102.1/dist/README.md -> 404 (release assets not mirrored)
2026-10-30	www.jsdelivr.com/terms/acceptable-use-policy	jsDelivr CDN sets no limit on bandwidth or on the number of requests
2026-10-30	www.jsdelivr.com/terms/acceptable-use-policy	jsDelivr CDN is free
2026-10-30	www.jsdelivr.com/terms/acceptable-use-policy	the GitHub-proxy recommendation is at most 10 000 actively accessed files per repository
2026-10-30	www.jsdelivr.com/terms/acceptable-use-policy	the GitHub-proxy soft limit is 100 000 files per repository
2026-10-30	www.jsdelivr.com/terms/acceptable-use-policy	the soft limits are not automatically enforced
2026-10-30	www.jsdelivr.com/terms/acceptable-use-policy	not published
2026-10-30	github.com/jsdelivr/jsdelivr/issues/18550	a jsDelivr member states the GitHub-proxy per-file limit of 20 MB
2026-10-30	www.jsdelivr.com/terms/acceptable-use-policy	served immutable files can outlive upstream deletion

Unknown values 2

per object cap notes: the field may be stated in a source that was not read
retention notes: the field may be stated in a source that was not read

jsDelivr

Egress and tunnels

www.jsdelivr.com/CDN for package contentegress/jsdelivrJSON compare report an error

Free allowance: Free CDN for npm and GitHub content only
Verdict: fails: quotathe free allowance is too small to matter
Cost: not stated
Identity: anonymousno card, no phone
Binding limit: per-object-capserves npm and GitHub content only, at package-file sizes
Evidence: reported1 source; a third party said so
Freshness: stale on 2026-11-06checked 2026-10-22 (live); stale on 2026-11-06

Free tier	free CDN for npm and GitHub content only unit none; metered on downloaded-bytes
Price	none stated
Limits	per-object-cap (binding) serves npm and GitHub content only, at package-file sizes source
Identity	anonymous no account to read from the CDN
Egress	no bandwidth cap found on a first-party page
Per-object cap	package-file sizes; the per-file class limit could not be read
Interface	rest https://cdn.jsdelivr.net/npm/PKG@VER/FILE
Tooling	curl
Composes with	not a general egress path: the bytes must already be in a package registry, so it composes with npm and not with a user's corpus.
Reliability	the policy page at /policy returned 404 on 2026-10-22; /terms and /about resolve

Evidence 1

date	source	what it proved
2026-10-22	probe: `https://www.jsdelivr.com/policy`	404 on 2026-10-22, so the per-file limit and the no-cap claim could not be read first-hand

More fields 3

stale after days	180
bytes transit	yes
transit note	the CDN serves package files from its edge