Web-Font Licensing and Self-Hosting: A Practical Rights Checklist
Understand what permission to use a typeface covers before you convert it, subset it, or serve it to a browser.
A font preview, a download button, and a license grant are three different things. Before a font becomes part of a website, identify who owns the files, which license governs them, and what that license permits for your exact delivery model. Desktop use, website serving, application embedding, modification, and redistribution may have different terms. Do not treat a font's visual availability in a tool as permission to copy its files into production.
Read the License for the File You Received
Start with the license packaged alongside the font and the foundry's current terms. Record the family and version, source URL, copyright notice, license name, and any limits that apply to web delivery. Some licenses require a separate web tier or domain plan; others allow broad redistribution with conditions. The file extension does not tell you its license, and converting a file does not expand the rights its author granted.
The SIL Open Font License is a useful example, not a shortcut for evaluating every family. Its text permits licensed font software to be used, modified, embedded, and redistributed under stated conditions. Its FAQ specifically discusses web pages and @font-face distribution, along with notices, modified versions, and reserved font names. Apply those terms to fonts actually released under the OFL. Read the license shipped with the specific family rather than assuming every open-looking download uses the same rules.
Commercial foundry licenses may define web use by monthly page views, domains, or an explicit number of font files. A service may authorize loading through its stylesheet while restricting direct download or self-hosting. Keep the purchase record and current terms with the project assets. If a site changes domain, traffic scale, or delivery provider, recheck the agreement instead of relying on a note from an earlier design phase.
Metadata Is Not the Whole License
OpenType's OS/2 fsType field records embedding-permission flags used in certain font workflows. It can help software understand restrictions for document or application embedding, but it is not a replacement for the rights holder's full license and should not be treated as universal web-hosting permission. Read the terms and file metadata together where relevant. If they appear inconsistent, ask the rights holder or qualified counsel before shipping.
The file is downloadable, so it can be converted, subset, and hosted on any website.
The license is recorded, website serving and planned modifications are permitted, and required notices remain with the shipped package.
Exact permissions depend on the family and license; this workflow is a recordkeeping practice, not legal advice.
Make Self-Hosting Reproducible
/* Confirm the font license before deployment. */
@font-face {
font-family: 'Licensed Display';
src: url('/fonts/licensed-display.woff2') format('woff2');
font-weight: 400;
font-style: normal;
font-display: swap;
}CSS records where a browser can find a file; it does not grant permission to publish that file.
Self-hosting gives a team control over URLs, caching, privacy, and deployment behavior, but it also makes the team responsible for retaining notices and serving only permitted files. Store the license beside the original assets and include any required attribution in the repository or credits. Keep generated build output limited to approved faces. A CDN changes the delivery location, not the rights attached to the font.
If a family is subset or converted, check whether the license treats that operation as a modification and whether metadata, copyright lines, or reserved names must be preserved or changed. Keep the untouched original, transformation command, tool version, and generated output distinguishable. This helps with rights review and makes future rebuilds dependable, especially when a teammate might otherwise mistake a derivative file for the author's original release.
Third-party font services need the same specific review. Their plan may set domain or traffic limits, allow stylesheet delivery but prohibit file downloads, or define what happens when a subscription ends. Keep a record of the provider and plan, permitted domains, and renewal status. A provider serving the typeface on your behalf does not automatically transfer ownership of the source files or authorize a different delivery method.
A Lightweight Rights Review
Make this check part of asset intake rather than a launch-week scramble. The person selecting a typeface may not be the person configuring the build or CDN, so write the answer where the next maintainer can find it. A small site may only need a text record beside its font files; a larger product can link each family to a procurement record and deployment configuration. The important part is that the decision can be repeated.
- Identify the exact family, version, source, and license text.
- Confirm web delivery, domains, traffic limits, modification, and subset rights.
- Retain required copyright, license, and reserved-name information.
- Keep original and generated files distinguishable and reproducible.
- Recheck the terms when the font source or deployment changes.
A sound rights workflow is specific: file, license, operation, destination, evidence. When any part is unclear, hold that family's deployment and choose a typeface with terms the team can verify. This avoids relying on folklore such as all free fonts being open for any use or a desktop license automatically covering a website. The relevant permission is the one stated for the way the file will actually be used.