Font File Inspector: Read Font Metadata Before You Ship a Typeface

A font file is not just a bag of letter shapes. Open one up and it carries name records (family, style, version), a glyph count, the character ranges it covers, and embedding and license flags that say whether you are even allowed to put it on the web. Most of us never look at any of that. We get a .ttf from a designer, drop it into a CSS @font-face block, and hope the browser does the right thing. Then the heading renders in the wrong weight, or a customer in Warsaw sees boxes instead of accented letters, and nobody knows why.

Inspecting the file first answers those questions before they become production bugs. This guide walks through what lives inside a font file, how to read it, and when that two-minute check saves you a redeploy.

What a Font File Actually Stores

TrueType (.ttf) and OpenType (.otf) files share an sfnt container made of named tables. WOFF and WOFF2 are the same data wrapped and compressed for the web. The pieces that matter most when you are auditing a font are:

• Name records (the name table): family name, subfamily/style, full name, PostScript name, and the version string. The PostScript name is the one design tools, PDFs, and some loaders quietly key on.
• Units per em (head table): the coordinate grid the outlines are drawn on, usually 1000 for OpenType and 2048 for TrueType. It tells you the design resolution.
• Glyph count (maxp table): how many glyphs the font defines. A 240-glyph font and a 3,400-glyph font are very different tools even if both call themselves "Inter."
• Character coverage (cmap table): which Unicode code points map to glyphs. This is the real answer to "does this font support Vietnamese?" or "will it render the em dash?"
• Embedding and license flags (OS/2 fsType bits): whether the foundry permits installable embedding, restricted embedding, or no embedding at all. Web use depends on these.

The single most important thing to internalize: the internal family name is not the filename. A file called BrandSans-Bold.ttf may report a family of "Brand Sans Display" and a subfamily of "SemiBold." If your CSS declares font-family: "Brand Sans Bold", the browser silently falls back to a system font, and you will not notice until someone screenshots the wrong page.

A Worked Example: Verifying a Font Before Use

Say a designer hands me three near-identical files and tells me "use the regular one for body text, it supports Polish." I do not take that on faith. I run each file through the Font File Inspector and read the report.

For the file corp-text-rg.ttf, the inspector reports:

• Family name: Corp Text
• Subfamily: Regular
• PostScript name: CorpText-Regular
• Version: Version 2.104
• Units per em: 1000
• Glyph count: 1,184

Now the language question. Polish needs characters like ą, ć, ę, ł, ń, ó, ś, ż, ź. A glyph count of 1,184 is healthy, but count alone does not prove coverage, so I check that those code points actually map to glyphs. With all of them present, the font genuinely covers Polish, and I can declare font-family: "Corp Text" (the internal name, not corp-text-rg) with confidence. If even one of those characters were missing, I would know to ask for a fuller cut before any of it reached a Polish-speaking user, instead of debugging a fallback after launch.

That whole check takes about ninety seconds and replaces a guess with a fact.

Checking License and Embedding Before the Web

Technical metadata tells you what a font can do; it does not replace your license agreement. The fsType embedding bits in the OS/2 table are a foundry's machine-readable hint: "Restricted License embedding" means the font should not be embedded at all without explicit permission, while "Installable" or "Editable" embedding is permissive. Web serving via @font-face is its own grant that many commercial licenses charge separately for.

So the rule I follow is simple. Read the embedding flags to catch obvious red lines early, but always confirm the actual right to use against the purchase or license document. An inspector that surfaces the family name and version also gives you the exact strings to paste into a license record, so six months later you can prove which version of which family you shipped.

Inspection Runs Locally, and That Matters

Here is the part teams often miss: you do not need to upload a font anywhere to inspect it. Font tables are plain structured data, and reading them is something a browser can do entirely on your own machine. The Font File Inspector parses the file locally and builds its report and CSV in the browser. The font bytes never leave your computer.

That is not a minor convenience. Unreleased brand fonts and licensed commercial typefaces are exactly the files you should not be dropping into a random online converter. Local inspection means you can audit a foundry's restricted font, or a client's confidential brand kit, without violating the license or leaking the asset. Privacy and correctness happen to point the same direction here.

Building a Font Manifest for Your Repo

Once you are inspecting individual files, the natural next step is to record what you have. Before font files go into a repository, I write down a small manifest per file: internal family name, subfamily, version string, glyph count, the languages it covers, and where it came from. The CSV the inspector exports is most of that manifest already.

This pays off in three recurring situations:

1. Duplicate weights. A brand package often ships "Bold" twice from two vendors. Matching version strings and glyph counts tells you which one is actually current.
2. Vendor handoffs. When a new agency takes over, a manifest of exact internal names removes a week of "which file is the real heading font?"
3. Provenance. Pair each font with a checksum so you can prove a file was not silently swapped. Run the file through a file hash calculator and store the digest next to the metadata.

A Quick Pre-Flight Checklist

Before you wire a font into a stylesheet, run through this:

• Read the internal family and subfamily name and use those exact strings in your CSS, not the filename.
• Confirm the glyph count is plausible for the cut you expect (a "full" family with 200 glyphs is suspicious).
• Verify the character ranges cover every language and symbol your UI renders, including punctuation like curly quotes and the em dash.
• Note the version string so future updates are traceable.
• Glance at the embedding flags, then confirm real rights against your license agreement.

None of this requires installing the font or trusting a third-party server. The inspector reads the tables, you read the report, and a category of "why is the type wrong" bugs simply stops happening.

Fonts are infrastructure. Treat each file like a dependency you would pin and audit, and the surprises move from production back to your local machine where they belong.

---

Made by Toolora · Updated 2026-06-13