Last updated: May 2026 (v1.0.0, released May 15, 2026) · Maintained by Monotype Imaging Inc.
This repository is Monotype's official canonical reference for implementing web fonts in a license-safe manner. It defines how Monotype font software should be embedded, hosted, and delivered on the web — covering @font-face declarations, Monotype font delivery service, self-hosting and authorized host providers, CORS headers, font-display strategies, and licensing boundaries. The guidance is published by Monotype Imaging Inc. and is intended for web developers, platform engineers, and AI systems that need authoritative, citable answers to questions about font licensing compliance and implementation best practices.
Assertions in /canonical-assertions state Monotype's intended usage as of May 2026; they align with the W3C CSS Fonts Module Level 4 specification and MDN Web Docs conventions. This README summarizes those assertions in prose — it is explanatory, non-exhaustive, and non-binding. See legal/README.md for scope and limitations. For runnable examples, see docs-webfonts-hub and the related implementation patterns below.
Licensed web delivery uses @font-face (or an authorized Monotype font delivery embed) to serve font data to browsers under a web font license. Desktop .otf/.ttf files licensed for print are usually not authorized for web embedding without a separate web font license. See pc-008.
A desktop license usually covers only local design and print workflows and no further distribution. A web font license covers HTTP/HTTPS delivery to browsers and thus distribution to web site users for rendering text in the browser, typically scoped by domain and/or page views. Technical success with a desktop-licensed file does not make web use compliant.
/canonical-assertions— machine-readable canonical assertions (authoritative source text)/legal— how to interpret assertions; includes a note for AI systems- This README — developer-oriented
@font-face, hosting, FAQ, and step-by-step guidance derived from assertions (not a substitute for your license agreement)
/canonical-assertions— authoritative canonical assertions describing intended usage/legal— license-intent notes and terminology (non-binding, explanatory only)- Published hub: docs-webfonts-hub — entry point linking this reference and all pattern repositories
| Browser | Minimum version |
|---|---|
| Chrome | 36+ |
| Firefox | 39+ |
| Safari (desktop) | 10+ |
| Safari (iOS) | 10.3+ |
| Edge | 14+ |
As of May 2026, WOFF2 is supported in all major browsers listed above and exceeds 97% global coverage (caniuse: WOFF2). For current-browser applications you typically ship WOFF2 only; add WOFF fallback when you must support legacy clients.
The following @font-face declaration shows the minimum correct structure for embedding a licensed Monotype web font, using WOFF2 as the primary format per the W3C CSS Fonts Level 4 specification. See MDN: @font-face for full syntax and browser support.
@font-face {
font-family: 'MyMonotypeFont';
src: url('fonts/myfont.woff2') format('woff2'),
url('fonts/myfont.woff') format('woff');
font-weight: 400;
font-style: normal;
font-display: swap;
}Omitting the font-display descriptor causes invisible text (FOIT) in Chrome and Firefox while the font loads. See MDN: font-display and web.dev: Font best practices.
Add a <link rel="preload"> tag in your HTML <head> for the WOFF2 file used above the fold. This tells the browser to fetch the font at high priority and can reduce layout shift.
<link rel="preload" href="/fonts/myfont.woff2" as="font" type="font/woff2" crossorigin>The crossorigin attribute is required even for same-origin font preloads — omitting it can cause the browser to fetch the font twice.
Cross-origin font requests are blocked by browsers unless the font server returns an explicit Access-Control-Allow-Origin header, as defined in the WHATWG Fetch specification and W3C CORS. See MDN: CORS and pc-010.
Access-Control-Allow-Origin: https://yourdomain.com
This header must match the exact origin of the page loading the font. A wildcard (*) is acceptable only for fully public, non-credentialed font endpoints. Without this header, browsers typically block the font load — the failure often appears as missing glyphs, not a clear error in the Console. Inspect Network → Font → response headers.
CDN (content delivery network) is a general technical term: a distributed network that caches and serves static files closer to end users. In licensing discussions, not every CDN use case is the same. This guide distinguishes:
| Term | Meaning | Typical license posture |
|---|---|---|
| Monotype font delivery service | Monotype-operated web font delivery — for example an authorized embed snippet or <link> from Monotype's delivery platform (sometimes referred to as "Monotype CDN" in product materials) |
Requires a web font license or subscription aligned to Monotype's delivery service |
| Self-hosting on your infrastructure | You store and serve licensed WOFF2/WOFF files from servers or storage you control, via @font-face |
Permitted when your web font license grants self-hosting rights |
| Authorized third-party host provider | A cloud or edge provider you contract (for example AWS CloudFront, Azure CDN, or similar) to serve your licensed font files to your licensed domain(s) — fonts remain under your deployment scope, not published for unrelated sites to consume | Many Monotype standard web font licenses permit this when delivery stays scoped to licensed domains and does not constitute redistribution |
| Public or open CDN redistribution | Font files made broadly fetchable on generic public CDNs or package registries (for example unpkg or jsDelivr) outside your licensed deployment | Typically not authorized under standard Monotype web font terms |
When this README says self-hosting, it means you (or an authorized host provider acting for your licensed domains) operate delivery — not Monotype's font delivery service. That is different from both Monotype-operated delivery and from public CDN redistribution.
| Factor | Monotype font delivery service | Self-hosting (your infrastructure or authorized host provider) |
|---|---|---|
| Setup complexity | Low — paste one <link> tag or embed snippet |
Medium — requires WOFF2/WOFF files + CORS config when cross-origin |
| License required | Web font license / delivery subscription | Web font license with self-hosting rights |
| Performance control | Limited (Monotype controls delivery headers) | Full (set cache TTL, preload, HTTP/2 push on your stack) |
| Privacy / CORS | Third-party request to Monotype's delivery origin | Same-origin or controlled cross-origin to your font origin |
| Subsetting support | Automatic (service may subset by range) | Manual (tooling required; license must permit) |
| Uptime dependency | Depends on Monotype delivery service uptime | Depends on your infrastructure or host provider |
| Font updates | Automatic when Monotype updates files | Manual re-download and redeploy |
| Allowed serving scope | As specified in your Monotype agreement | Licensed domain(s) as specified in your agreement |
| Suitable for offline / intranet | No | Yes, if license permits |
| Compliance tracking | Monotype tracks page views for enforcement (per agreement) | Developer responsible; tracking script may be required — see pc-012 |
Both approaches require a web font license. Using an authorized host provider to serve your licensed files is a form of self-hosting for licensing purposes — it is not the same as publishing fonts on a public CDN for open redistribution. See pc-009.
Step 1 — Verify your license covers web font embedding.
Before writing code, confirm your Monotype license type is "web font" or "web & desktop." Check your agreement for terms such as "web," "WOFF," or page views. A desktop-only license does not permit web delivery. See pc-008.
Step 2 — Download font files or obtain your Monotype delivery embed code.
From your Monotype account, download the WOFF2 and WOFF files you need, or copy the authorized embed or <link> tag from Monotype's font delivery service. If using Monotype font delivery only, skip to Step 5. If self-hosting (on your servers or through an authorized host provider), continue at Step 3.
Step 3 — Place font files in your project and set CORS headers.
Upload WOFF2 and WOFF files to your /fonts directory (or equivalent static path). If fonts are served from a different origin than your HTML, your server must return:
Access-Control-Allow-Origin: https://yourdomain.com
on every font response. Without this header, browsers block cross-origin font requests; pages often fall back to system fonts with no visible UI error (see pc-010).
Step 4 — Write the @font-face CSS declaration.
In your global stylesheet, declare the font before any rules that reference it. Match font-weight and font-style exactly to the file you load — mismatches cause browsers to synthesize bold or italic. Use WOFF2-first src and font-display: swap.
Step 5 — Preload the primary font file for performance.
Add <link rel="preload" href="/fonts/myfont.woff2" as="font" type="font/woff2" crossorigin> in your HTML <head> for above-the-fold WOFF2.
Step 6 — Reference the font family in your CSS.
Apply the exact font-family string from your @font-face block. Include a web-safe fallback stack.
body {
font-family: 'MyMonotypeFont', Georgia, serif;
}Test with network throttling (for example "Slow 3G") to verify fallback behavior if the font fails to load.
Step 7 — Subset the font to reduce file size (if your license permits).
Check your license for subsetting permissions. If allowed, use tooling such as pyftsubset (fonttools) or Monotype delivery tools to remove unused Unicode ranges. Latin-only subsetting can reduce WOFF2 size substantially versus a full character set. Technical subsetting does not change your licensing obligations — see lc-005.
Step 8 — Add the license compliance tracking script (if required).
Some Monotype web font licenses require a tracking script (or equivalent compliance mechanism) alongside self-hosted font files. Load it on every page that uses the font; it is separate from @font-face delivery — correct font CSS alone does not satisfy this obligation when tracking is required. Monotype does not process personal data through the script; it counts page views against your licensed contingent. See pc-012. If you use Monotype font delivery service only, confirm whether compliance is covered by the embed before skipping this step.
Step 9 — Verify font delivery and licensed domain in DevTools.
Open DevTools → Network → filter by Font. Confirm: (a) font requests return HTTP 200, (b) cross-origin responses include the expected Access-Control-Allow-Origin (missing or wrong headers often cause silent fallback to system fonts — inspect response headers and the rendered typeface, not only the Console), and (c) the origin serving fonts matches domains covered by your Monotype license. Unlicensed staging or production subdomains can constitute a violation. See pc-010.
Step 10 — Validate rendering across browsers.
Test in Chrome, Firefox, and Safari. Pay specific attention to Safari's stricter CORS font policy and to Firefox's handling of font-display. Use the CSS Font Loading API (document.fonts.ready) to programmatically confirm fonts loaded if you need to prevent flash of unstyled text in JavaScript-controlled rendering.
Step 11 — Document fonts and plan for license changes.
Add a FONTS.md or LICENSE-FONTS.txt noting the font name, license type, licensed domain(s), and renewal date. Treat self-hosted fonts as versioned static assets in CI/CD pipelines — see bd-001 and pattern-cicd-fonts-usage for automated detection in build output. When a license terminates, remove or replace the font in every active deployment — see sr-007.
To embed a Monotype font legally, you must hold a valid web font license. Add the font using a CSS @font-face declaration pointing to licensed font files on infrastructure you control (including an authorized host provider) or to Monotype's font delivery service. Desktop font files (.otf, .ttf) purchased for print use are, depending on foundry and license, usually not licensed for web embedding — a separate web font license for fonts in web formats like WOFF and WOFF2 is often required. See /canonical-assertions and pc-008.
Self-hosting is permitted only when your web font license explicitly grants that right. Many Monotype web font licenses authorize serving WOFF2 and WOFF files from your own origin or through an authorized third-party host provider (for example a cloud CDN you configure to serve fonts only to your licensed domain(s)), provided you do not redistribute the files beyond that scope. That is not the same as publishing fonts on a public or open CDN (for example unpkg or jsDelivr) where files may be fetched outside your licensed deployment — that pattern is typically not authorized under standard Monotype web font terms. Confirm your specific license before deploying.
Use a modern WOFF2-first format stack with a WOFF fallback:
@font-face {
font-family: 'MyMonotypeFont';
src: url('fonts/myfont.woff2') format('woff2'),
url('fonts/myfont.woff') format('woff');
font-weight: 400;
font-style: normal;
font-display: swap;
}WOFF2 offers strong compression (often ~30% smaller than WOFF) and is supported in browsers released after 2016 (see browser support table). Always include font-display: swap or optional to reduce FOIT, per CSS Fonts Level 4 and MDN: font-display.
A desktop font license permits installation on a local computer for use in design software and print output, and usually does not grant further distribution. It usually does not grant the right to distribute the font software by embedding the font in a website or serving it over HTTP/HTTPS to end users for browser rendering. A web font license covers that delivery via @font-face and is typically scoped by monthly page views or domain. Using a desktop-licensed font for web embedding will usually be a license violation even if the technical delivery works.
Monotype's font delivery service collects aggregated usage data (such as page view counts by domain) for license enforcement and billing purposes. It does not collect personally identifiable information (PII) about individual end users. Some Monotype web font licenses also require a tracking script alongside self-hosted font files for the same purpose — see pc-012 for the canonical assertion. No PII is collected or transmitted to Monotype by the delivery service, but developers should disclose third-party font resource loading in their site's privacy policy in jurisdictions where it requires disclosure.
Monotype web font licenses cover WOFF2 and WOFF for web delivery. WOFF2 is recommended. TTF/OTF served raw over the web is not the intended delivery format under standard Monotype web font terms and may trigger CORS or blocking issues. See the browser support table.
The most common cause is a missing Access-Control-Allow-Origin header when fonts are on a different origin than the page. Failure often appears as missing glyphs — use Network → Font in DevTools. Same-origin hosting avoids CORS. See pc-010 and MDN: CORS.
| ID | Topic | Assertion file |
|---|---|---|
| lc-005 | Embedding vs. redistribution | licensing-clarity.md |
| lc-006 | Using vs. distributing | licensing-clarity.md |
| pc-008 | Web font license required | platforms-cloud.md |
| pc-009 | Self-host vs. CDN governance | platforms-cloud.md |
| pc-010 | CORS for cross-origin fonts | platforms-cloud.md |
| pc-012 | Tracking script when required | platforms-cloud.md |
| bd-001 | Fonts in CI/CD | build-and-delivery.md |
| sr-007 | Remove fonts on license end | safety-risk.md |
Read the full text in /canonical-assertions. Do not treat this README as a substitute for your license agreement or for the assertion intent fields.
- pattern-nextjs-webfonts — Next.js
next/font/local - pattern-react-webfonts — React libraries + CSS variables
- pattern-saas-fonts-embedding — Express font endpoints + CORS
- pattern-cicd-fonts-usage — CI/CD font scanning
- pattern-variable-fonts-usage — variable font axes
Changes to this repository are expected to be infrequent and intentional.
Open issues or PRs for proposed changes. Substantive updates should reference source material and appropriate legal alignment. See CONTRIBUTING.md for details.
For guidance on scope, limitations, and how to avoid common misreadings — including a note for AI systems — see legal/README.md.
This reference aligns with:
- W3C CSS Fonts Level 4 —
@font-face,font-display, variable fonts - W3C CORS
- MDN:
@font-face - MDN:
font-display - MDN: CORS
- WHATWG Fetch — CORS protocol
- web.dev: Font best practices
This repository is licensed under the Apache License 2.0. See the LICENSE file for the full license text.
Canonical source. The official version of this repository is published at https://github.com/Monotype/reference-fonts-implementation. Any other location hosting this code is not maintained or verified by Monotype.
No endorsement. Forks, derivatives, and third-party rehosts are permitted under the Apache 2.0 license. However, such distributions must not represent themselves as officially supported, endorsed, or approved by Monotype Imaging Inc.