jsDelivr: A Free Production CDN for npm, GitHub, and Open-Source Files

What jsDelivr Provides and Who It Is For

Open-source library authors publish their packages to npm or GitHub and typically ask users to include them via a CDN link. Hosting those files on a personal server or relying on a single CDN introduces a single point of failure. jsDelivr addresses this by providing a free CDN that integrates directly with npm and GitHub, requires no account or configuration from the package author, and is designed to handle traffic from production websites of any scale.

The README states the positioning directly: "We offer a stable CDN that can be used in production on popular websites with huge amounts of traffic. There are no bandwidth limits or premium features, and it's completely free to use."

The primary audience is front-end developers who include libraries such as jQuery, Bootstrap, or icon font CSS in HTML pages via script or link tags. Secondary audiences include package authors who want their projects to have a reliable CDN URL without maintaining infrastructure, and application developers who use the public API to query package metadata.

How jsDelivr Delivers Files: Multi-CDN, RUM Load Balancing, and Failover

jsDelivr uses multiple CDN providers simultaneously. At the time of the last README update, these were Cloudflare and Fastly. If one provider goes down, traffic switches to the remaining providers without any action from the user or the website owner.

Load balancing uses Real User Monitoring (RUM) data. Hundreds of websites contribute performance measurements from real visitors, and this data feeds the routing algorithm so each user gets served from the fastest available provider based on their location, ISP, and real-time provider performance. The system responds immediately to performance degradation: if a CDN is under a DDoS attack and slows for users in a region, the algorithm switches those users to a different provider within seconds.

For DNS, jsDelivr uses two DNS providers simultaneously. Both monitor the load-balanced endpoint, and if either detects problems, they switch all traffic to a single CDN provider automatically. The origin consists of multiple servers in different data centers with automatic failover between them.

How to Use jsDelivr: npm, GitHub, and URL Patterns

The root endpoint is always `https://cdn.jsdelivr.net`. All file URLs are constructed from this base.

To load a specific file from an npm package at an exact version:

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

To use a version range instead of an exact version:

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

To load the latest version (not recommended for production):

/npm/jquery@latest/dist/jquery.min.js
/npm/jquery/dist/jquery.min.js

GitHub files are served from the /gh/ endpoint using a similar pattern. The README notes that for npm packages, new versions pushed to npm are instantly available via the CDN. No maintenance is required by the package author.

WordPress plugins can also be served from a dedicated endpoint, and the README mentions that jsDelivr provides mirrors for WordPress plugins alongside npm and GitHub.

Permanent Storage and Version Fallback

The feature that most distinguishes jsDelivr from simpler CDN proxies is its permanent storage policy. When a file is first accessed, it is stored permanently in a reliable file system. This means that if an npm package is deleted or a developer removes a file from GitHub, jsDelivr continues to serve the stored copy without breaking any websites using it.

The README states the policy explicitly: "If a package, version, or file gets removed from npm, then jsDelivr will continue to serve that file from our permanent storage without breaking any websites using it." A separate S3 storage backs this: files are fetched directly from npm only the first time or when S3 is unavailable.

Version fallback extends this further. If a file exists in version 1.0.1 of a package but is no longer present in version 1.0.2, and a user requests the file at version 1.0.2, jsDelivr falls back to the 1.0.1 copy instead of returning a 404 error. This behavior applies to version range requests in production and is worth understanding before using ranges: the served file may be older than the declared range when the newer version removes a path.

China Delivery and Privacy Considerations

jsDelivr maintains nodes close to Chinese urban centers. The README notes this explicitly to address the common CDN problem of poor performance for visitors in mainland China from CDN nodes located only in Europe and North America.

Regarding privacy, the repository includes a Privacy Policy.md and a Sub-Processors.md file. The README mentions that a jsDelivr Net Tracker appears in searches, which refers to analytics or monitoring associated with the CDN. The repository includes a Terms of Use.md, indicating that use of the CDN is subject to those terms.

The CDN collects request data to power the RUM load-balancing system. Teams in privacy-sensitive jurisdictions should review the Privacy Policy before embedding jsDelivr URLs in production applications.

Limitations and When jsDelivr Is the Wrong Tool

jsDelivr only serves files that are publicly accessible. Private npm packages and private GitHub repositories cannot be served through the CDN. Any file that requires authentication to access on npm or GitHub is not available via jsDelivr.

Using the latest tag or omitting the version in a CDN URL is explicitly flagged as not recommended for production. The README explains why: requesting the latest version means the URL may serve different content over time as new versions are published, which can introduce breaking changes without warning.

The /combine/ endpoint for concatenating multiple files into a single request is listed as a dynamic endpoint. Like /npm/ and /gh/, it is treated as permanent once first accessed, but the README does not document a dedicated combine URL format in the portion of the README available in the repository.

For files not in npm or GitHub, the README notes that the project can sometimes accommodate special requirements: "If our regular endpoints don't work for your use case, let us know and we'll figure something out."

Maintenance, License, and Alternatives

The repository is not archived. The last push was on 2026-06-27. The repository is licensed under MIT. The repository itself (github.com/jsdelivr/jsdelivr) is primarily documentation and configuration; the CDN infrastructure, the website code, and the public API are in separate repositories linked from the README.

The most direct alternative is cdnjs, which also provides a free CDN for open-source JavaScript libraries. The difference in approach is that cdnjs requires libraries to be manually submitted and reviewed before they appear on the CDN, while jsDelivr provides direct access to any publicly available npm package or GitHub repository without a submission process.

unpkg is another npm-focused CDN alternative. Like jsDelivr's npm endpoint, it serves files directly from npm packages. jsDelivr differentiates with its multi-CDN infrastructure, China nodes, permanent storage policy, and GitHub endpoint.

Editorial conclusion

jsDelivr suits open-source library authors and front-end teams who need a free, production-grade CDN for publicly available npm packages or GitHub repositories with no configuration required. It is not suitable for private packages or files that are not publicly accessible on npm or GitHub. Before using version ranges or the latest tag in production, confirm that the version-fallback behavior matches your tolerance for serving older files when a package update removes a path. The cdn.jsdelivr.net root endpoint is the stable production address; the /combine/ endpoint for file concatenation and dynamic endpoints like /npm/ are treated as permanent once first accessed.

Frequently asked questions

Official sources

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