Font Metadata for Designers and Web Developers

Font metadata sits at the intersection of typography, law, and technical implementation. Most of the time you don't think about it. Then you use a font in a commercial project and get a cease-and-desist from a type foundry, or you deploy a @font-face stylesheet with a font that has fsType 2 (Restricted), or a client hands you a font file and you have no idea if it's the right version.

This guide breaks down which metadata fields matter to designers, which matter to developers, and how to check any of them in under a minute using a browser-based viewer.

What Designers Need to Know About Font Metadata

For graphic designers, the two metadata fields that matter most are license text and version.

License text (nameID 13) — This is the authoritative statement of what you can do with the font. Not the font download site's description. Not the foundry's marketing page. The text embedded in the file. Before using a font for client work, check this field:

• Is commercial use explicitly permitted?
• Are there restrictions on specific use types — advertising, product packaging, broadcast?
• Is attribution required?
• Is modification or redistribution allowed?

Version string (nameID 5) — When collaborating with a client or another designer, font version mismatches cause subtle layout differences that are difficult to diagnose. If a document renders differently on two machines using "the same font," check the version string on both files. If they differ, they're not actually the same.

What Web Developers Need to Know About Font Metadata

For web developers, the critical fields are fsType and weight class.

fsType (embedding permissions) — Before adding a font to a @font-face CSS rule, check that the fsType value permits web embedding. The relevant values:

• 0 — Installable. Web embedding is unrestricted. ✓
• 2 — Restricted. Web embedding is not permitted. ✗
• 4 — Print and Preview. Generally interpreted as not covering web use. ✗
• 8 — Editable. Gray area for web; check the foundry's terms. ⚠

Weight class — The usWeightClass value in the OS/2 table is what the operating system uses to match a font file to a CSS font-weight value. If a font's weight class is 700 but you're declaring it as font-weight: 400, the browser may use synthetic bolding. Checking the weight class confirms the file matches your CSS declaration.

Sell Custom Apparel — We Handle Printing & Free Shipping

Unicode Ranges and Glyph Count: Relevant to Both Designers and Developers

Unicode ranges tell you which character blocks the font supports — Basic Latin, Latin Extended, Cyrillic, Greek, Arabic, etc. Before committing a font to a project, check that it covers the scripts you need.

For designers: if you're setting text in multiple languages in a document, confirm the single font covers all the scripts. Discovering a missing Cyrillic block after the design is approved means font substitution and visual inconsistency.

For developers: the unicode-range descriptor in CSS @font-face lets you serve different font subsets for different character ranges. The unicode ranges metadata tells you which subsets the font actually covers so you can write accurate CSS.

Glyph count is a secondary indicator of comprehensiveness. A font with 2,500 glyphs in a family you expected to be basic Latin-only may contain stylistic alternates, small caps, or historical ligatures that your license doesn't cover under standard terms. Or it may just be a particularly complete Latin font. The unicode ranges clarify which.

Checking Any Font's Metadata in 15 Seconds

The WildandFree Font Metadata Viewer reads all the fields covered in this guide from any TTF, OTF, or WOFF file. No install. No upload. Everything is processed locally in your browser.

Drop the file. The output includes: family name, designer, version, copyright, license text, license URL, glyph count, weight class, unicode ranges, and fsType embedding flags.

This is the fastest way to answer the two questions designers and developers most frequently need to answer about a font:

1. Can I use this for [project type]? → Check the license text and fsType.
2. Is this the same font as the one on the other machine/in the design file? → Check the version string and family name.

Building Font Metadata Checks Into Your Workflow

For studios and freelancers handling multiple client font assets, a lightweight metadata check at the start of each project prevents licensing issues from surfacing at the worst time. The check takes 15 seconds; a foundry letter demanding retroactive licensing fees takes weeks to resolve.

A simple pre-project checklist:

• Drop every font provided by the client into the viewer
• Check the license text — confirm it covers the planned deliverable type (print, web, broadcast, product)
• Check fsType — if the project includes a web component, confirm 0 or a compatible value
• Note the version string — record it in the project file for reproducibility

This takes under two minutes for a typical font set and creates an auditable record of due diligence.

Frequently Asked Questions

Do I need to check font metadata for every project?

For OFL or Apache-licensed fonts (all Google Fonts, many open-source fonts), no — the license is clear and comprehensive. For fonts from font download sites, client-supplied fonts, or purchased desktop licenses, yes. The 15-second check is worth building into your workflow.

What's the most important font metadata field?

For designers, license text. For developers, fsType. For both: version string when collaborating with others on the same files.

Can I check multiple fonts at once?

The browser-based viewer handles one file at a time. For batch checking (auditing a library of dozens of fonts), fonttools on the command line is the better option — it can be scripted to output all metadata for every file in a directory.