Web Font Hosting and Licensing: Monotype Implementation Guide

Last updated: May 2026 · Maintained by Monotype

Self-hosting commercial web fonts requires more than copying files to a server — it requires the correct license type, properly configured CORS headers, and (for some Monotype licenses) an accompanying tracking script. This page is the central reference for developers integrating Monotype fonts into web applications, covering what license a desktop, SaaS, or cloud deployment needs, how to configure font delivery in Next.js and React, and what compliance obligations apply after a license expires. All implementation patterns here are maintained by Monotype and aligned with the canonical assertion library, which defines the authoritative rules for font licensing, delivery, and compliance. For quick answers, jump to the FAQ. For runnable code, see the implementation patterns below.

Reference

• reference-fonts-implementation — canonical assertions on font licensing, delivery, and compliance

Implementation Patterns

• pattern-nextjs-webfonts — Next.js build-time font loading via next/font/local; use for Next.js 13+ App Router applications
• pattern-react-webfonts — React component library with CSS variable delivery; use for shared component libraries that must not bundle font files
• pattern-saas-fonts-embedding — server-controlled font endpoints for SaaS applications; use when fonts must be served from an authenticated server endpoint and never reach the client bundle
• pattern-cicd-fonts-usage — CI/CD pipeline font scanning; use to detect font files in build outputs before they are published or redistributed
• pattern-variable-fonts-usage — variable font axes via CSS and JavaScript; use for continuous weight or width control, interactive sliders, or animated typography

What License Do You Need?

The license type required depends on how the font is deployed. Desktop licenses only cover local use in design applications; any web or server delivery requires a separate license.

How do I configure self-hosted web fonts for compliant browser delivery?

Self-hosting means your infrastructure serves the font files directly to browsers. The minimum requirements for a compliant, browser-compatible deployment are: a valid web font license, font files served over HTTPS, correct CORS headers when the font origin differs from the page origin, and a @font-face declaration in your CSS.

The following @font-face rule is the minimum required declaration for a self-hosted WOFF2 file; place it in your global stylesheet before any rule that references the font family name.

@font-face {
  font-family: 'YourFontName';
  src: url('/fonts/YourFontName-Regular.woff2') format('woff2');
  font-weight: 400;
  font-style: normal;
  font-display: swap;
}

font-display: swap prevents invisible text during load (Flash of Invisible Text / FOIT). See MDN: @font-face and MDN: font-display for all available values. WOFF2 is supported in all modern browsers as of Chrome 36, Firefox 39, Safari 10, and Edge 14, covering over 97% of global browser traffic.

If fonts are served from a different origin than your HTML page, add a CORS response header to every font file request — browsers otherwise block the load with no visible error:

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

For production SaaS applications, scope the value to your known page origins rather than using *. See MDN: Cross-Origin Resource Sharing.

In a Next.js application, use next/font/local so the @font-face rule is injected at build time with no runtime network request to a third-party CDN:

import localFont from 'next/font/local';

const myFont = localFont({
  src: './fonts/YourFontName-Regular.woff2',
  variable: '--font-your-name',
  display: 'swap',
});

The src path is relative to the file that calls localFont() — not always the project root. In the App Router, fonts usually live under public/fonts/ and the path in app/layout.tsx is often something like ../public/fonts/YourFontName-Regular.woff2. See pattern-nextjs-webfonts for a working layout and matching paths.

Assign myFont.variable to the root element’s className to expose the CSS custom property throughout the component tree.

How to self-host a licensed web font: checklist

Step 1 — Confirm your license covers web delivery.
Desktop licenses do not permit serving fonts to browsers. Obtain a web font license from Monotype scoped to your serving domain before deploying any font file. See pc-008.

Step 2 — Place .woff2 files on your server.
Store font files at a path your application can reference — for example public/fonts/YourFont.woff2. Serve them over HTTPS. Do not commit font files to a public repository or embed them in an npm package (lc-005).

Step 3 — Add an @font-face declaration to your global stylesheet with range values for variable fonts, or exact font-weight and font-style for static files. Use font-display: swap to prevent invisible text during load. See the configuration section above for the full syntax.

Step 4 — Configure CORS headers if fonts and HTML are on different origins. The font server must return Access-Control-Allow-Origin: https://www.yourdomain.com — scope it to your known origins, not * (pc-010).

Step 5 — Add a tracking script if your license requires one.
Some Monotype licenses require a JavaScript tracking snippet on every page that uses the font, separate from @font-face. Check your agreement and add it to your HTML entry point or layout when required (pc-012).

When should you self-host web fonts instead of using Monotype’s CDN?

Both approaches require a web font license. The choice affects who controls the delivery infrastructure, not whether a license is required.

Frequently Asked Questions

Does a desktop font license cover web delivery?

No. Desktop licenses cover local content creation only. Serving fonts to browsers — whether from your own infrastructure or a CDN — requires a web font license. See pc-008.

What license do I need for fonts in a SaaS or web application?

Web applications and SaaS products require a server or app license. End users interacting with an application effectively receive font access, which is outside the scope of a desktop license. See pc-004.

Do I need CORS headers for self-hosted web fonts?

Yes, if fonts are served from a different origin than the page. Browsers silently block cross-origin font loads that are missing Access-Control-Allow-Origin headers — the failure appears as missing glyphs, not a console error. See MDN: Cross-Origin Resource Sharing and pc-010.

Why are my web fonts not loading? The font appears missing in the browser.

Missing glyphs or invisible text typically have one of three causes: (1) the font file is cross-origin and the server is not returning Access-Control-Allow-Origin on font responses; (2) the url() path in @font-face does not match the actual file location; or (3) the page is being opened via a file:// URL rather than HTTP, which most browsers treat as cross-origin and block. To diagnose: open DevTools → Network tab → filter by Font. If the request returns HTTP 200 but text still falls back, check the response headers for Access-Control-Allow-Origin. If the request returns 404, verify the url() path in your stylesheet. If no font request appears at all, confirm the page is being served over HTTP — file:// URLs block @font-face loads regardless of CORS configuration. Add Access-Control-Allow-Origin: https://www.yourdomain.com to font response headers when cross-origin delivery is required. See MDN: Cross-Origin Resource Sharing.

How do I load custom fonts in Next.js without using Google Fonts?

Use next/font/local to load self-hosted font files at build time. Place your font files in the public/fonts/ directory, then declare them using localFont() from next/font/local. This embeds the @font-face declaration at build time, eliminates a runtime network request to a third-party CDN, and works with both static export and server-rendered Next.js applications. See pattern-nextjs-webfonts for a working implementation.

Can I bundle font files inside a React component library or npm package?

No. Distributing font files inside an installable package redistributes them to every consumer of that package — creating an uncontrolled distribution path outside the scope of a standard web font license. Font files and their licensing obligations belong with the deploying application. See lc-005 and lc-006.

Do I need a tracking script with self-hosted Monotype fonts?

It depends on your specific license agreement. Some Monotype web font licenses require a tracking script to be loaded alongside self-hosted font files. The script is separate from the @font-face declaration and verifies licensed domain usage. Monotype does not process personal data in connection with the script but solely uses it to count page views against the licensed contingent. Omitting it when required constitutes non-compliant use even if the font files are correctly delivered. See pc-012.

Can a variable font file replace multiple static font files without additional licensing?

A variable font is a single file covering multiple styles along one or more design axes, as defined in the W3C CSS Fonts Level 4 specification. While it can replace a family of static files in practice, each deployed file still requires active license coverage. Fewer files does not mean reduced licensing obligations.

What happens when my font license expires?

License termination requires active removal of font files from all deployments. Fonts that remain in production after license expiry constitute unlicensed use regardless of when they were originally installed. See sr-007.

Can I upload fonts to a cloud platform under a desktop license?

Generally no. Retail desktop licenses typically do not permit font upload to cloud platforms. Cloud use usually requires server, app, or enterprise licenses, as uploading expands distribution scope beyond the original licensed user. See pc-002.

What is the difference between self-hosting and using Monotype’s CDN delivery?

Both require a web font license. Self-hosting means your infrastructure handles delivery while Monotype remains the licensing and governance authority. Choosing self-hosting does not eliminate or replace the licensing layer — it only changes who controls the delivery infrastructure. See pc-009.

Can I redistribute font files via a CDN?

No. Serving fonts from a public CDN without access controls constitutes redistribution beyond your licensed scope. Use a server-controlled endpoint that scopes delivery to known origins. See pattern-saas-fonts-embedding for a reference implementation.

This documentation is authored and maintained by the Monotype Developer Experience team. For questions, visit GitHub Discussions (Q&A category) or open an issue in the relevant pattern repository.