A font file is a container of tables, and most of what you need to know before shipping one is sitting in those tables — not in the filename, which lies as often as not. Type reads them on your machine and tells you the truth.
Drop a .ttf, .otf or .woff and you get:
- Family, style and version from the
nametable — the real names, in the font's own words. - Metrics from
head,hheaandOS/2: units per em, ascent and descent, the weight and width class, cap height and x-height. This is what decides whether two "regular" fonts actually line up. - Embedding permission from the
fsTypebits, in plain words. This is the one people skip and then regret — a font marked no embedding is not one you can legally ship in an app, and the file says so plainly. - Coverage: which Unicode blocks the
cmapactually maps. A "supports Cyrillic" claim is easy to check here — either the block is covered or it isn't.
Why "trust the file, not the name"
Filenames are set by whoever exported the font, and they drift. Helvetica-Bold.ttf might be a knock-off at weight class 400. The weight class in OS/2 is the number the browser actually uses when you write font-weight: 700, so that is the number worth reading:
usWeightClass 700 (Bold)
usWidthClass 5 (Medium / normal)
sxHeight 1062
sCapHeight 1462
fsType 0 (installable — embedding permitted)
Seeing it, not just reading it
Below the data, Type renders a live specimen with the font actually loaded from the same bytes — a waterfall of sizes and an editable sample string — so you can read the numbers and see the face at once. WOFF2 is compressed with a codec browsers keep to themselves, so its full metadata isn't parsed, but it still rasterises, so you get the specimen either way.
Nothing is uploaded. The parsing happens in your browser, which is exactly where a decision about a file on your disk should happen.