How to coverage map vs glyph count: different questions, different answers
- Step 1Run the Glyph Count Analyzer first — Drop the font into [glyph-count-analyzer](/font-tools/glyph-count-analyzer). It reports total glyphs and projected WOFF2 sizes for common subsets — your performance picture.
- Step 2Run the Coverage Map on the same font — Drop the same file here. It reports `N of 346 blocks covered`, total unique codepoints, and per-block percentages — your language picture.
- Step 3Compare total glyphs to unique codepoints — The Coverage Map's metric chips show both total glyphs and total codepoints. A large gap (5,000 glyphs, 250 codepoints) means the font is mostly stylistic alternates, not extra languages.
- Step 4Map glyph count to your bandwidth budget — Use Glyph Count's projected WOFF2 sizes to decide what you can afford to ship. A 20,000-glyph CJK font is hundreds of KB even subset; a 250-codepoint Latin face is tiny.
- Step 5Map coverage to your audience — Use the Coverage Map's per-block percentages to confirm the font covers every script your users read. Coverage, not count, decides language fitness.
- Step 6Decide with both numbers together — A font is only right when its coverage matches your locales and its size fits your budget. Either metric alone can mislead — 5,000 glyphs of the wrong script is worse than 300 of the right one.
Glyph Count vs Coverage Map — what each answers
The two analysers read the same font but report different things. This is the decision matrix for which to trust for which question.
| Dimension | Glyph Count Analyzer | Coverage Map |
|---|---|---|
| Core question | How many glyphs / how big? | Which scripts are covered? |
| What it counts | Total glyphs (encoded + unencoded) | Unique encoded codepoints, bucketed into 346 blocks |
| Includes alternates/ligatures? | Yes — they're glyphs | No — unencoded glyphs aren't counted |
| Headline number | Total glyph count + WOFF2 size projections | N of 346 blocks covered + codepoints |
| Drives the decision | Bandwidth / performance budget | Language / audience fitness |
| Output format | JSON | HTML matrix (.coverage.html) |
| Answers 'will my page be slow?' | Yes | No |
| Answers 'will Russian render?' | No | Yes |
Same glyph count, different story
Why count alone is misleading. Three hypothetical fonts at ~5,000 glyphs with very different coverage and purpose.
| Font | Total glyphs | Unique codepoints | Coverage Map says | Right for |
|---|---|---|---|---|
| Display face A | 5,000 | 250 | 4 blocks: Latin + symbols, lots of swashes/alternates | Headlines, Latin-only branding |
| Pan-European B | 5,000 | 3,100 | 14 blocks: Latin, Cyrillic, Greek, Vietnamese | Multilingual body text |
| Partial-CJK C | 5,000 | 4,800 | CJK 23%, Latin 100% | Nothing reliably — too little CJK to be useful |
| Icon font D | 5,000 | 5,000 | Private Use Area only | Custom UI icons, never running text |
Cookbook
Worked comparisons that show why you need both numbers. Each pairs a Glyph Count read with a Coverage Map read of the same font.
Two fonts, same count, opposite fitness
ExampleGlyph count says they're equal. Coverage says one is Latin-only and one is multilingual. Coverage breaks the tie.
Glyph Count Analyzer: Font A total glyphs: 5,012 Font B total glyphs: 4,988 → 'basically the same' Coverage Map: Font A 4 of 346 blocks 250 codepoints (Latin + symbols) Font B 14 of 346 blocks 3,100 codepoints (Latin/Cyrl/Greek) Verdict: identical counts, completely different fonts. For a Russian audience, only Font B works.
The 5,000-glyph font that encodes 250 codepoints
ExampleA high glyph count can be mostly unencoded alternates. The gap between total glyphs and codepoints reveals it.
Coverage Map metric chips: Total glyphs: 5,000 Total codepoints: 250 Unicode blocks: 4 / 346 Reading: 4,750 glyphs are unencoded — swashes, ligatures, stylistic sets reachable only via OpenType features. They inflate the count and the file size but add zero languages. Coverage, not count, is the language signal.
Subset planning: count for size, coverage for what to keep
ExampleGlyph Count tells you how small a subset gets; Coverage Map tells you which characters you'd be keeping.
Glyph Count Analyzer (projected WOFF2): Full font 412 KB latin subset 28 KB latin+cyrillic 46 KB Coverage Map (what those subsets contain): Latin Basic + Latin-1 191 / 191 100% Cyrillic 255 / 256 99% Decision: 46 KB buys full Latin + Cyrillic. Build it with /font-tools/font-subsetter, then re-run Coverage Map to verify.
Don't subset toward coverage the font doesn't have
ExampleIf Coverage Map shows 23% CJK, no subsetting can recover the missing 77%. Count won't tell you this; coverage will.
Coverage Map: CJK Unified Ideographs U+4E00-U+9FFF 4,820 / 20,992 23% Glyph Count says 'plenty of glyphs' — but 23% CJK means 77% of Chinese characters will tofu no matter what you subset. Pick a different font; subsetting can only remove, not add.
Icon font: high count, zero language coverage
ExampleAn icon font reports thousands of glyphs but all in the Private Use Area — no real script coverage at all.
Glyph Count: 5,000 glyphs Coverage Map: Private Use Area U+E000-U+F8FF 5,000 / 6,400 78% (no Latin, no anything else) This is a UI icon font, not a text font. Count looks rich; coverage confirms it renders no running text. Use it for icons only — see /font-tools/glyph-inspector to view each symbol.
Edge cases and what actually happens
Every row below was probed against the live API. Some documented requirements (alphabetical axis order, numerical tuple order) are not actually enforced in practice — useful to know if you've been blaming the wrong thing for a 400.
Total glyphs far exceeds unique codepoints
ExpectedNormal for expressive type. The extra glyphs are unencoded alternates, ligatures, swashes, and small-caps reachable only through OpenType features. They count toward glyph total and file size but not toward coverage, because an unencoded glyph can't be typed and can't fix tofu. The gap is a feature-richness signal, not a coverage one.
Unique codepoints exceeds the visible glyph forms you'd expect
ExpectedOne glyph can map to several codepoints (the tool reads both glyph.unicode and the multi-mapped glyph.unicodes). A single glyph serving, say, both the micro sign and Greek mu counts as coverage for two codepoints. So codepoint count can slightly outpace naive glyph intuition.
High glyph count, low coverage — partial CJK
Misleading countA font with 5,000 glyphs that are 80% CJK still only covers ~23% of the 20,992-codepoint CJK block. The count looks generous; the coverage is unusable for real Chinese text. This is the single most important reason never to rank fonts by glyph count alone.
Icon font reports thousands of glyphs, no script coverage
ExpectedIcon fonts map glyphs into the Private Use Area (U+E000–U+F8FF). Glyph Count shows a big number; Coverage Map shows only the PUA block. That's correct — PUA codepoints have no standard meaning, so the font covers no real language. Inspect individual icons with the glyph-inspector.
Two outline formats, same coverage and count
By designCFF (PostScript) and TrueType outlines can encode identical character sets. Neither the count nor the coverage distinguishes outline flavour — both read the cmap. For the outline format, use the Font Format Identifier; count and coverage are outline-agnostic.
Variable font — count and coverage are per-family, not per-weight
SupportedA variable font has one glyph set and one cmap shared across all axes. Glyph Count and Coverage Map both report the whole family once; you don't get different numbers for Bold vs Light. File size, however, varies if you instance a static weight first.
Coverage 100% but glyph count surprisingly low
ExpectedA minimal, well-built font can hit 100% Latin coverage with a lean glyph count and no alternates — efficient, not deficient. Low count is only a problem if coverage is also low. Read them together: 100% of your needed scripts at a low count is the ideal lightweight font.
Glyph Count's WOFF2 projection vs Coverage Map's block list
ComplementaryGlyph Count projects subset sizes; Coverage Map lists what's in each subset's range. Use the projection to pick an affordable subset and the coverage to confirm that subset contains the characters you need — they answer adjacent halves of the same decision.
Frequently asked questions
Why does my font have 5,000 glyphs but only 250 codepoints?
The other 4,750 glyphs are unencoded — alternates, swashes, ligatures, and stylistic sets reachable only via OpenType features (salt, ss01, liga, etc.). They have no cmap entry, so they count toward total glyphs and file size but not toward Coverage Map's codepoint total. You can't type an unencoded glyph, so it can't fix tofu.
Which tool should I use to pick a font?
Both. Glyph Count for the bandwidth/performance picture (total glyphs, projected WOFF2 subset sizes) and Coverage Map for language fitness (per-block coverage across 346 blocks). A font is only right when its coverage matches your audience and its size fits your budget.
Can a higher glyph count ever be worse?
Yes. A 5,000-glyph font that's mostly stylistic alternates of the wrong script is heavier and no more useful than a 300-glyph font that covers exactly your languages. Count drives bytes; coverage drives fitness. Optimise for coverage of what you need, then minimise bytes.
Does the Coverage Map output JSON like the Glyph Count tool?
No. The Coverage Map produces an HTML matrix saved as .coverage.html. The Glyph Count Analyzer outputs JSON. If you need machine-readable coverage data, replicate the block-bucketing in Node — the automation guide shows how.
How does the percentage relate to glyph count?
They measure different denominators. Coverage percentage is covered codepoints ÷ block size (e.g. 95 of Basic Latin's 128). Glyph count is the raw number of glyph outlines. A font can be 100% Latin (every Latin slot mapped) yet have far more glyphs than Latin slots, because of unencoded alternates.
Why might unique codepoints slightly exceed what I expect?
Because one glyph can serve multiple codepoints. The micro sign (U+00B5) and Greek small mu (U+03BC) often share a glyph; the tool counts both codepoints via glyph.unicodes. So the codepoint total reflects mapped codepoints, which can exceed distinct glyph shapes.
For subsetting, which number matters?
Coverage first, count second. Coverage tells you which characters exist to keep; count (and its size projection) tells you how small the kept set gets. You can only subset down to what the font already covers — subsetting never adds glyphs.
Does either tool show OpenType features like ligatures?
Neither shows feature behaviour. Glyph Count counts ligature glyphs as glyphs; Coverage Map ignores them if unencoded. To inspect actual OpenType features (GSUB/GPOS), use the OpenType Features Inspector.
Can I tell from coverage whether a font will be slow?
No — coverage says nothing about file size. A 250-codepoint font can be a heavy display face, and a 3,000-codepoint font can be lean. For the speed question, use Glyph Count's WOFF2 size projections and then ttf-to-woff2 to compress.
What if coverage is high but I still see tofu?
Either the missing characters fall in the small uncovered percentage, or the issue is shaping (complex scripts) rather than coverage. Identify the exact failing character, find its codepoint, and check whether its block row in the Coverage Map shows it as covered.
Do both tools run locally?
Yes. Both parse with opentype.js in your browser — nothing uploads. You can run Glyph Count and Coverage Map back-to-back on the same file with the badge reading 0 bytes uploaded throughout.
How do I combine both into a procurement decision?
Run Glyph Count and Coverage Map on each candidate, then tabulate: coverage of required locales (go/no-go) and projected subset size (budget). Pick the smallest font that covers every script you ship. Download the .coverage.html per candidate as the attached evidence.
Privacy first
Every JAD Font tool runs entirely in your browser using opentype.js and the wawoff2 WASM Brotli encoder. Your fonts never leave your device — verified by zero outbound network requests during processing.