Font Web Embedding Restrictions

WOFF and WOFF2 Format Requirements

Web Open Font Format (WOFF) and its successor WOFF2 are the standard delivery formats for web fonts. WOFF2 offers roughly 30% better compression than WOFF, making it the preferred format. Modern web font licenses typically provide font files pre-packaged in WOFF/WOFF2 format specifically for web delivery.

WOFF and WOFF2 files include a metadata block that can contain license and copyright information. This metadata travels with the font file and is one mechanism foundries use to identify their fonts in the wild.

While browsers also support TTF and OTF via @font-face, web font licenses often provide WOFF/WOFF2 specifically. Using raw TTF/OTF on the web may not be covered by your web license unless the EULA explicitly permits it.

Format Conversion: Is TTF to WOFF2 Legal?

Converting a font from TTF or OTF to WOFF2 is a gray area that depends entirely on your specific license. Different foundries take very different positions:

• OFL fonts:The SIL Open Font License explicitly allows format conversion. Converting Google Fonts from TTF to WOFF2 for self-hosting is fully permitted.
• Commercial fonts:Many EULAs prohibit “modification” of font files. Some treat format conversion as modification; others do not. When in doubt, use the format provided by the foundry.
• Restrictive licenses:Some licenses explicitly state that only files provided by the foundry may be used, prohibiting any re-encoding or conversion.

If your license is unclear on format conversion, contact the foundry directly before converting. Most are responsive to licensing questions and will clarify in writing.

Domain Restrictions in Web Licenses

Most commercial web font licenses are domain-locked. A license for one domain covers that domain and its subdomains only. Deploying the same font files on a second domain (even if you own both) requires a separate license. Enterprise agreements often allow a specified number of domains, which reduces per-domain cost at scale. Always check the domain count clause before deploying across multiple web properties.

When Self-Hosting Is Permitted

When a web font license grants self-hosting rights, you receive the WOFF/WOFF2 files to host on your own server. This is the most common model for fonts purchased outright (as opposed to subscription services). Myfonts, Fontspring, and many independent foundries sell licenses that include self-hosting.

Self-hosted fonts offer several practical advantages beyond just licensing. You control caching headers, eliminating third-party latency. You remove a privacy dependency on external services (relevant for GDPR compliance). You retain full functionality if the foundry's CDN experiences downtime. For performance-critical applications, self-hosting is often the technically superior choice.

When Foundry-Hosted Service Is Required

Subscription-based font services (Adobe Fonts, Fonts.com, Linotype) often tie the license to using their delivery infrastructure. You receive a JavaScript embed code or an @import URL rather than downloadable font files. This model lets the service track pageview compliance in real time and revoke access automatically if a subscription lapses.

Under these models, downloading or caching the font files locally and serving them yourself is a license violation, even if you are an active subscriber. The license is conditional on delivery through the service's CDN. If you want self-hosting rights, check whether the service offers a “desktop use” or “self-hosted web” add-on.

Open-Source Fonts: Always Self-Hostable

Fonts licensed under the SIL Open Font License (OFL), Apache 2.0, or Creative Commons licenses that permit redistribution can always be self-hosted. There is no pageview cap, no domain restriction, and no requirement to use any particular delivery service. Google Fonts fall into this category; you can download them and self-host them freely.

Self-hosting Google Fonts has become increasingly recommended since a 2022 German court ruling found that loading fonts from Google's CDN violated GDPR by transmitting visitor IP addresses to Google without consent. Self-hosting eliminates this data-sharing entirely.

Your Own CDN (Permitted Where Self-Hosting Is Permitted)

If your license permits self-hosting, it generally permits hosting on your own CDN infrastructure. Serving fonts via Cloudflare, Fastly, AWS CloudFront, or similar services as an extension of your own web infrastructure is covered under self-hosting rights. The CDN is acting as a performance layer for your server, not as an independent hosting provider.

Confirm that the CDN domain is associated with your licensed domain if the license is domain-locked. Some foundries require the CDN hostname to be a subdomain (e.g., cdn.yourdomain.com) rather than a third-party CDN hostname.

Hotlinking: Strictly Prohibited

Hotlinking means referencing font files hosted on another site's server directly in your CSS without permission. For example, copying an @font-face URL from another website and pointing your CSS at their server to avoid hosting the files yourself. This is almost universally a license violation and also constitutes bandwidth theft.

The exception is services that explicitly authorize referencing their URLs, such as Google Fonts CDN (fonts.googleapis.com) or Adobe Fonts (use.typekit.net). These services provide embed codes specifically intended to be loaded from their CDN under their terms of service.

Google Fonts CDN vs Self-Hosted

Google Fonts provides two delivery methods: loading via their CDN with a <link> tag, or downloading files to self-host. Both are permitted under the open-source licenses covering Google Fonts. The CDN method is simpler to implement; self-hosting gives you performance control and eliminates the Google data-sharing concern.

Importantly, you cannot use Google's CDN infrastructure for fonts not in the Google Fonts catalog. The CDN service is only for the specific fonts Google hosts, under their specific API terms.

Third-Party Font Redistribution: Never Permitted

Uploading commercial font files to a public CDN, file-sharing service, or npm registry for general access is redistribution and is prohibited under virtually all commercial font licenses. This includes uploading to GitHub public repositories, public S3 buckets, or public CDNs where anyone could reference your files. If you use private repositories or access-controlled storage, the risk is lower, but review your license for explicit redistribution prohibitions.

Typical Tier Structure

Most commercial web font licenses use monthly pageview tiers. Tier boundaries vary by foundry, but a common structure is:

Tier names and boundaries vary by foundry. Always check your specific EULA for the exact numbers.

What Counts as a Pageview?

Font license pageview definitions do not always match analytics pageview definitions. Most foundries count a pageview as any request to load a page that serves the font. Bots, crawlers, and automated traffic typically do not count, but verify this in your EULA. Some licenses count unique pageviews; others count total requests including repeat visits from the same user.

If you use a foundry CDN service, pageview tracking is often handled automatically. If you self-host, you are responsible for tracking against your licensed limit using your web analytics platform (Google Analytics, Plausible, Matomo).

Exceeding Your Pageview Cap

Exceeding the pageview cap in your license is a technical breach of contract. In practice, most foundries do not immediately sue for minor overages, but they can. The correct action when approaching your cap is to proactively upgrade to the next tier before you exceed it.

If you have been over cap for some time without upgrading, contact the foundry and ask about retroactive licensing. Many are willing to resolve the situation with a license upgrade rather than legal action, especially if approached in good faith before they discover the violation independently.

For sites with highly variable traffic (media sites, viral content), build in a buffer and purchase at least one tier above your typical monthly traffic. This prevents accidental overage during traffic spikes.

Negotiating Enterprise Agreements

For high-traffic sites (above 1 million monthly pageviews) or multi-domain deployments, direct negotiation with the foundry often yields better terms than published pricing. Enterprise agreements can bundle multiple domains, remove pageview caps, include desktop seats, and cover derivative brand applications such as apps and documents.

When approaching a foundry for enterprise licensing, come prepared with your traffic data, domain count, number of desktop users, and intended use cases (web, app, print, video). This allows the foundry to scope the license accurately and avoids surprise gaps later.

Why Browsers Block Cross-Origin Fonts

Browsers apply the same-origin policy to font requests. When a page on www.example.com loads a font from cdn.example.com (a different subdomain), the browser treats this as a cross-origin request. Without an Access-Control-Allow-Origin header on the font server's response, the browser will load the file but refuse to render it, causing a fallback to system fonts.

This is a common cause of web font rendering failures in production. Fonts may work perfectly in local development (same origin) but silently fall back to system fonts in staging or production where the CDN is a different origin.

Configuring CORS Headers for Self-Hosted Fonts

To allow cross-origin font loading from your own CDN or asset server, configure your server to respond with appropriate CORS headers for font file requests. The exact configuration depends on your server software.

Nginx configuration:

# In your server {} or location {} block
location ~* \.(woff|woff2|ttf|otf|eot)$ {
    add_header Access-Control-Allow-Origin "https://www.yourdomain.com";
    add_header Access-Control-Allow-Methods "GET, OPTIONS";
    add_header Cache-Control "public, max-age=31536000";
    expires 1y;
}

Apache .htaccess configuration:

<FilesMatch "\.(woff|woff2|ttf|otf|eot)$">
    Header set Access-Control-Allow-Origin "https://www.yourdomain.com"
    Header set Access-Control-Allow-Methods "GET, OPTIONS"
    Header set Cache-Control "public, max-age=31536000"
</FilesMatch>

Express.js / Node.js middleware:

// Allow fonts only from your domain
app.use('/fonts', (req, res, next) => {
  res.setHeader(
    'Access-Control-Allow-Origin',
    'https://www.yourdomain.com'
  );
  res.setHeader('Access-Control-Allow-Methods', 'GET, OPTIONS');
  res.setHeader('Cache-Control', 'public, max-age=31536000');
  next();
});

Wildcard vs Specific Origins

You can set Access-Control-Allow-Origin: * to allow any domain to load your fonts. While technically simpler, this is a licensing risk for commercial fonts with domain restrictions. Any website could hotlink your font files, consuming your pageview tier and potentially violating your license's exclusivity requirements.

For commercial fonts, restrict CORS to your specific origin or a whitelist of your own domains. For open-source fonts (OFL, Apache 2.0) where redistribution is permitted, a wildcard origin is acceptable and simplifies CDN configuration.

CORS and the @font-face src Descriptor

The crossorigin attribute in a <link rel="preload"> tag for fonts must be set to ensure the browser uses the same credentials mode as the actual @font-face fetch. Without this, the browser may make two separate requests (one for preload, one for the actual font) rather than reusing the cached response.

<!-- Correct font preload with crossorigin attribute -->
<link
  rel="preload"
  href="https://cdn.yourdomain.com/fonts/brand.woff2"
  as="font"
  type="font/woff2"
  crossorigin="anonymous"
/>