How to host fonts on a CDN: step‑by‑step guide.

Global language support

By Jeff Carey, Sr. Principal Software Engineer and Developer Relations Lead

Last updated: July 17, 2026.

Hosting fonts on a Content Delivery Network (CDN) enhances your website’s performance, scalability, and reliability by serving font files from servers located closer to your users. Whether you’re a designer managing brand assets or a developer optimizing web performance, this guide walks through each step of setting up, configuring, and maintaining fonts on a CDN—while ensuring licensing compliance and a consistent user experience.

Understanding font hosting on a CDN.

A CDN, or Content Delivery Network, is a globally distributed system of servers that caches and delivers web assets—including fonts—from locations geographically closest to each user. This reduces latency and minimizes page load times.

CDN font hosting allows your typography to render faster worldwide by reducing the distance between the user’s browser and your font files. Compared with local hosting, CDNs offer:

Faster global load speeds and consistent uptime.

Optimized bandwidth usage and reduced load on your origin server.

Improved Core Web Vitals through more efficient font rendering and caching.

For large brands and platforms, CDN‑based web font delivery supports seamless, scalable experiences across every digital touchpoint.

CDN delivery is not one licensing pattern. In this guide, “CDN” can mean different things:

Term	Meaning	Typical license posture
Monotype font delivery service	Monotype-operated web font delivery (authorized embed or product CDN)	Covered when your agreement includes Monotype delivery
Self-hosting on your infrastructure or an authorized host provider	You serve licensed WOFF2/WOFF files from servers or a cloud/edge CDN you control (or that hosts for your benefit under a written agreement), scoped to your licensed domain(s)	Often permitted under a standard Monotype web font license when delivery stays within that scope
Public or open CDN redistribution	Font files made broadly fetchable on generic public CDNs or package hosts (for example jsDelivr or unpkg), outside your licensed deployment	Typically not authorized under standard Monotype web font terms

The steps below focus on self-hosting via your own origin or an authorized host provider. They are not instructions for publishing commercial Monotype font software on a public open CDN.

See also: Monotype Font Delivery vs. Self-Hosting in the reference repository.

Step 1: Verify font licensing and reporting requirements

Before uploading fonts anywhere, confirm that your license allows web embedding and the delivery method you plan to use. A desktop license does not cover browser delivery. A web font license typically does — but “CDN” in the contract or in documentation may still need a careful read.

Under many Monotype web font agreements, serving licensed files from infrastructure you control — including an authorized third-party host provider (for example a cloud CDN configured for your licensed domain(s)) — is treated as self-hosting, not as a separate product you must buy only because an edge cache is involved. That is different from Monotype’s own font delivery service, and different again from placing files on a public or open CDN where unrelated sites can fetch them.

Also check reporting and tracking obligations. Some Monotype web font licenses require usage reporting (for example by monthly pageviews) and, for self-hosted delivery, may require a tracking script alongside the font files. Those obligations can apply regardless of whether fonts are served from your origin or through an authorized host.

License / path	Browser delivery	Your CDN / host for your domains	Public open CDN (e.g. jsDelivr)	Reporting / tracking
Desktop	No	No	No	N/A
Standard web font (typical)	Yes	Often yes, if scoped to you	Usually no	Per agreement
Monotype web font	Yes	Yes, when the agreement allows	No	Often yes — check your terms
Monotype font delivery	Yes	N/A (Monotype serves)	N/A	Per product terms

Confirming these details early helps prevent compliance issues and avoids building on a delivery model your license does not allow.

Step 2: Prepare and optimize font files for CDN delivery

Before uploading, optimize your font files to reduce load time and improve performance. The most effective approach is to serve your fonts in WOFF2 format—the industry standard for web compression—offering roughly 30% smaller file sizes than WOFF.

Subset your fonts to include only the characters and styles your site needs. Removing unused glyphs, weights, and extensions further reduces file size and speeds up delivery.

A clean, optimized font kit should include:

WOFF2 (primary format)

WOFF/TTF (optional fallback for older browsers)

This preparation ensures fast, efficient CDN delivery while maintaining typographic quality.

Step 3: Upload fonts to your chosen CDN

Select infrastructure that matches both your performance needs and your license.

For commercial Monotype fonts, prefer a host or CDN under your control (or under a written hosting arrangement for your benefit), with delivery scoped to your licensed domain(s). Upload font files to your storage or origin (for example an object store) and configure the CDN distribution to serve those assets. This is the usual authorized host provider / self-hosting path described in Step 1.

If your agreement includes Monotype font delivery, you may not need to upload production font files to your own CDN at all — Monotype operates delivery under that product. Use that path when it fits your license and workflow.

Approach	Best for	Notes for licensed Monotype fonts
Commercial cloud CDN / static host (e.g. Cloudflare, CloudFront, BunnyCDN, Azure CDN)	Production sites that self-host	Generally appropriate when scoped to your licensed domains and covered by your agreement
Monotype font delivery service	Teams that want foundry-operated delivery	Use when included in your license; not the same as self-hosting on your CDN
Public open CDN / package host (e.g. jsDelivr, unpkg)	Some open or freely redistributable fonts	Not recommended for commercial Monotype font software — files become broadly fetchable outside your licensed deployment
Versioned open registries (e.g. Fontsource-style public links)	Public font ecosystems	Same caution: do not treat as a license-safe host for proprietary Monotype files

For commercial networks such as Cloudflare or CloudFront, upload optimized WOFF2 files to your bucket or origin and point the CDN at those objects. Keep production-licensed files out of public repositories whenever possible and restrict who can fetch them to the domains your license covers.

Step 4: Configure CDN caching and compression settings

Caching and compression are critical for speed and consistent rendering. Caching stores font files both at CDN edge servers and in the user’s browser, allowing repeat visits to load instantly.

Follow these configuration guidelines:

Set long Time‑to‑Live (TTL) values with hashed filenames—for example, one year for edge and browser caches.

Enable compression (Gzip or Brotli) for font MIME types such as font/woff2 or application/font-woff.

Re‑deploy when file hashes change to ensure browsers always receive updated versions.

Aggressive caching with hashed filenames ensures near‑instant delivery and simple version control.

Step 5: Set up CORS headers and test cross‑origin access

Cross-Origin Resource Sharing (CORS) allows browsers to load fonts from a different origin than the page. If fonts are served from a CDN or host hostname that differs from your site origin, missing or incorrect CORS headers cause the browser to block the font — often as missing glyphs or a silent fallback to system fonts, not a clear on-page error. Inspect DevTools → Network → Font and the rendered typeface, not only the Console.

For licensed commercial fonts, set a scoped allowlist that matches your page origin(s):

Access-Control-Allow-Origin: https://www.yourdomain.com

Use your real site origin (scheme + host + port if needed). Prefer a specific origin over a wildcard. Access-Control-Allow-Origin: * is a common generic CDN example, but it is not appropriate for typical Monotype self-hosted or authorized-host delivery, where font access should stay limited to known licensed origins. If you serve multiple licensed front-end origins, configure allowlisting per origin (or the mechanism your CDN provides for varying Origin), and set Vary: Origin when responses differ by requesting origin so shared caches do not reuse the wrong CORS header.

Where you apply headers depends on the provider:

Cloudflare: Transform Rules or Workers

CloudFront: origin response header policies

Object storage (e.g. S3): bucket or response header configuration

CORS setup checklist

Access-Control-Allow-Origin scoped to your licensed page origin(s) — not * for licensed fonts

Vary: Origin when applicable

Fonts tested in multiple browsers after a cache purge

CDN cache invalidated after header or file updates

Same-origin delivery (page and fonts on one host) usually needs no CORS configuration. Cross-origin delivery through an authorized host always does.

Step 6: Implement cache busting with hashed filenames

Cache busting ensures users receive updated font files even when browsers cache older versions.

Add a unique content hash to each updated file name, such as brand-sans-regular.a1b2c3.woff2. This lets CDNs and browsers store fonts long-term while instantly serving the latest version when hashes change.

After renaming, update all @font-face CSS references accordingly. Hashed filenames provide efficient version tracking without manual cache clearing.

Once your hashed font file is on the CDN, wire it into your stylesheet with an @font-face declaration. This tells the browser where to find the file and how to use it.

@font-face {

font-family: ‘BrandSans’;

src: url(‘https://cdn.example.com/fonts/brand-sans-regular.a1b2c3.woff2’) format(‘woff2’),url(‘https://cdn.example.com/fonts/brand-sans-regular.a1b2c3.woff’) format(‘woff’);

font-weight: 400;

font-style: normal;

font-display: swap;

}

Replace BrandSans with your actual font family name and update the URLs to match your CDN path. The font-display: swap property shows fallback text immediately, then swaps to the web font once it loads—a key contributor to a good Cumulative Layout Shift score.

Step 7: Add resource hints for optimal font loading

Resource hints tell browsers which resources to prioritize. For CDN-hosted fonts, proper hints can boost speed and stability.

Add a preconnect hint to establish an early connection to your CDN:

Then preload the specific font file that renders above the fold:

Combined with targeted preload and sensible font-display settings, these hints minimize blocking and help fonts render quickly and consistently across devices.

Hosting fonts on a CDN can improve performance, scalability, and reliability — when “CDN” means infrastructure you control (or an authorized host provider) serving licensed files to your licensed domains, or when you use Monotype’s own font delivery service under your agreement. It does not mean publishing commercial Monotype font software on a public or open CDN where unrelated sites can fetch the files.

To ship a fast, compliant setup: verify web font licensing and reporting or tracking requirements; optimize and subset fonts (prefer WOFF2; treat WOFF/TTF as optional fallbacks); upload to a suitable authorized host or use Monotype delivery; configure long-lived caching and compression; set scoped CORS headers when fonts are cross-origin and test in DevTools; use hashed filenames for cache busting; and add resource hints plus font-display: swap where appropriate. Following these steps supports consistent typography, stronger Core Web Vitals, and delivery that stays within your license scope.

Related resources

For licensing definitions (Monotype font delivery vs self-hosting vs authorized host provider vs public open CDN), see the canonical reference:

https://github.com/Monotype/reference-fonts-implementation#monotype-font-delivery-vs-self-hosting

For runnable self-hosting patterns: