jsDelivr: the free CDN that serves npm and GitHub files, and what its caching model means for you

What jsDelivr is and who it is for

jsDelivr is a free CDN for open-source files. The README states that it is tightly integrated with GitHub and npm, so it can automatically provide a CDN service to almost every open-source project. The stated audience is broad: package authors who want their files loadable from a short URL, and site owners who need a production-grade delivery path without paying for bandwidth. The README says there are no bandwidth limits or premium features, and that the service is completely free to use.

That combination is unusual. jsDelivr instead exposes dynamic endpoints that resolve a package name and version at request time, and the README explicitly says these endpoints are expected to be used in production. So the project is aimed at people who want to reference a specific file from a public package in a script tag or a stylesheet link, and at maintainers who want a stable URL for their distributed assets.

How the /npm/ and /gh/ endpoints resolve a request

The root endpoint is always `https://cdn.jsdelivr.net`. For npm, the path shape is `/npm/package@version/file`. The README gives `/npm/[email protected]/dist/jquery.min.js` as an exact-version example, and `/npm/jquery@3/dist/jquery.min.js` as a range example. Tags such as `@beta` and `@latest` are supported but the README marks them as not recommended for production usage, which is a sensible warning: a tag can move, an exact version cannot.

The mechanism behind the URL is a permanent store. The README says that when a file is first accessed it gets permanently stored in a reliable file system, and that files are fetched directly from npm only the first time or when S3 is down. That is the key architectural decision. The CDN is not a pass-through proxy; the first request materialises the file into jsDelivr's own storage, and later requests are served from there. The README states that if a package, version or file is removed from npm, jsDelivr continues to serve the stored copy. It also describes version fallback: if a file present in 1.0.1 is gone in 1.0.2, a request for the missing file in 1.0.2 falls back to the 1.0.1 copy instead of returning a 404.

Serving is multi-provider. The README names Cloudflare and Fastly as the CDN providers, with load balancing driven by real user measurement data gathered from websites, plus synthetic tests. Routing decisions are per user, based on location, ISP and provider uptime. The README also describes DNS-level failover across two DNS providers and an origin spread over multiple data centres.

Installing nothing: a first real request against the CDN

There is no package to install and no server to run. jsDelivr is consumed over HTTP, so the first real use is a request. The README gives the npm path shape directly, and this is the exact-version example it prints:

/npm/[email protected]/dist/jquery.min.js

Prepend the root endpoint to get a full URL. In a browser or with curl you should receive the minified jQuery file, served from one of the CDN providers. The README notes that new versions pushed to npm are instantly available, so no publishing step on jsDelivr's side is required.

A range works the same way, and the README shows both forms:

/npm/jquery@3/dist/jquery.min.js
/npm/[email protected]/dist/jquery.min.js

If you request a file that is missing from the newest matching version, the README says the version-fallback feature serves it from an older version instead of failing. That is the behaviour to expect when a range resolves to a release that dropped a file.

For GitHub-hosted projects the README points at the `/gh/` endpoint as one of the dynamic endpoints, alongside `/npm/` and `/combine/`. Check the usage documentation for the exact `/gh/` path shape before you build a path by hand. What the README does make clear is that `/gh/`, like `/npm/`, is treated as a production endpoint and benefits from the same permanent-storage behaviour.

The permanent-copy promise and its uncomfortable edge

The README frames permanence as a feature, and for the stated use case it is. A site that references `/npm/[email protected]/dist/file.js` keeps working after the author unpublishes the package, because jsDelivr holds a copy. Version fallback extends that to files that disappear between releases. For anyone who has watched a CDN 404 break a production page, this is the strongest argument for the project.

The same property is a limitation worth naming. Once a file is stored, jsDelivr's stated intent is to keep serving it forever. That means a package author who removes a file for a security or licensing reason cannot assume the removal propagates to every URL that already resolved. If your release process assumes that deleting an artefact from npm removes it from the internet, jsDelivr's caching model contradicts that assumption. Treat the first successful fetch as the moment the file becomes durable on a third party's storage.

A second edge is version fallback itself. It prevents 404s, but it can also serve a file from an older release when the newer one deliberately dropped it. If you depend on the absence of a file, or on a file only existing in a version you pinned, fallback can mask a packaging mistake rather than surface it.

Where jsDelivr is the wrong tool

jsDelivr is scoped to public sources. The README describes mirrors for npm, GitHub and WordPress plugins, plus custom endpoints for projects with special requirements. The npm endpoint is described as serving files from packages in the public registry, so a build pipeline that pulls internal artefacts should not route through these endpoints. Use your own registry or a private CDN instead.

The endpoints also are not a general-purpose object store. You cannot upload an arbitrary file and get a URL; the file has to exist in a public registry or repository that jsDelivr mirrors. If your asset is generated at deploy time, it does not belong here.

There is also a dependency question. Putting `cdn.jsdelivr.net` in a script tag means a third party sits in the critical path of your page load. The README describes extensive failover, but it also makes clear that the service is free, and the top of the README carries a call for contributors. That is not a reason to avoid it; it is a reason to know what you are relying on. If you are planning capacity for a high-traffic property, look for an SLA, rate limits or a support commitment in the full documentation and in the Terms of Use and Sub-Processors documents at the top level of the repository.

jsDelivr compared with cdnjs and a self-hosted bundle

A common comparison is cdnjs. The difference is in how content gets in. cdnjs is a curated library host: a fixed catalogue of popular libraries, each added and versioned through that project's own process. jsDelivr resolves dynamically against npm and GitHub, so any public package is addressable without being added to a catalogue. If you depend on a small or niche package, that difference decides the choice. If you only ever load jQuery, Bootstrap or an icon set, both work and the catalogue model is not a disadvantage.

The other real alternative is not a CDN at all: bundling the dependency into your own build and serving it from your own origin. That removes the third-party domain and the tag-versus-version question entirely, at the cost of owning the bytes and the cache headers. jsDelivr's advantage here is the permanent copy and the multi-provider routing; your own origin gives you control over removal, which jsDelivr's model deliberately trades away. Neither is universally better. Pick based on whether you value durability of the URL or control over the artefact.

Maintenance, licence and what the repository actually contains

The repository is not archived. Its last push was on 2026-10-05, about a month before this check, so the codebase is receiving changes. That says nothing about the operational reliability of the CDN itself, which the README describes but does not quantify. The repository has no published GitHub releases, which fits its shape: the top-level entries are `.github/`, `LICENSE.md`, `README.md`, `Privacy Policy.md`, `Sub-Processors.md` and `Terms of Use.md`, so this is the project's documentation and policy repository rather than a versioned library. The README points to separate repositories for the website and the public API, and says contributors are wanted, listing open issues in those repos as the place to start.

The licence is MIT, which is permissive and imposes no obligation on you to publish changes. Note the distinction: MIT covers the repository's code and documentation, not the third-party packages you serve through the CDN. Those carry their own licences, and jsDelivr does not change them. Reading the Terms of Use and Sub-Processors files is the practical step, because those documents set out the service terms and sub-processor list. This is not legal advice; if you need a contractual position, the documents in the repository are the ones to read.

Editorial conclusion

Adopt jsDelivr if you are publishing open source files and want a free origin that keeps serving them after a package is deleted or a file is removed, and if you can accept a third-party domain in your critical path. Do not adopt it as your only delivery route for private, non-open-source assets, or as a general-purpose origin for application builds, because the public endpoints are scoped to public registries and repositories. Before you commit, verify the exact version range or tag you plan to reference, confirm whether the file you need exists in the version you pin, and read the Terms of Use and Sub-Processors documents in the repository.

Frequently asked questions

Official sources

1. Issues
2. jsdelivr/jsdelivr on GitHub
3. License: MIT
4. Project website
5. README