How to glyph count vs coverage map for font selection
- Step 1List the languages and symbols you must support — Write the requirement first: e.g. "English + Polish + Czech, plus € and smart quotes." That maps to Latin Basic, Latin Extended, and the symbols block. Without the requirement, coverage numbers have nothing to be judged against.
- Step 2Run the coverage map for the fitness lens — Drop each candidate onto [the character coverage map](/font-tools/character-coverage-map). It scores against 346 Unicode blocks and shows per-block coverage. Check the blocks your requirement needs are at or near 100% — a font that's 60% covered in Latin Extended will render Polish with missing accents.
- Step 3Run the glyph count analyser for the size lens — Drop the same candidate onto this analyser. Read the projected WOFF2 size for the smallest subset that satisfies your requirement. This is the cost axis.
- Step 4Cross-reference on the two-axis matrix — Plot each candidate: x = smallest subset that covers the requirement (from coverage), y = projected KB for that subset (from glyph count). Viable candidates sit in the lower-left — well-covered and cheap.
- Step 5Eliminate the obvious losers — Drop anything under-covered (a required block below ~100% in the coverage map) regardless of how small it is, and anything over budget at every covering subset regardless of how pretty it is. Objective screens first.
- Step 6Decide among survivors on brand and licence — Among candidates that pass both screens, weigh design quality, brand fit, and licence terms. The two tools are objective filters; the final pick adds the subjective factors a tool can't judge.
What each tool actually measures
The two tools share a font but answer different questions. Mixing them up is the root of most selection mistakes.
| Dimension | Glyph Count Analyzer | Character Coverage Map |
|---|---|---|
| Question answered | How big after subsetting? | Which scripts/blocks does it cover? |
| Output | JSON: total_glyphs + projected WOFF2 per subset | HTML: per-block coverage across 346 Unicode blocks |
| Granularity | 6 fixed subsets (Latin, Latin Ext, Cyrillic, Greek, Vietnamese, symbols) | 346 real Unicode blocks |
| Counts what | Codepoints inside a subset's ranges + glyph total | How much of each block the font supports |
| Use it to decide | Cost / performance budget | Language fitness / will text render |
| Does NOT tell you | Whether a language fully renders | How many KB the font ships as |
Two-axis selection matrix (worked)
Three candidates against a requirement of English + Polish (needs Latin Basic + Latin Extended at ~100% coverage) and a 35 KB budget. Coverage from the 346-block map; size from the analyser's projection. Illustrative numbers.
| Candidate | Latin Ext coverage | Projected KB (Latin Ext subset) | Verdict |
|---|---|---|---|
| Font A | 100% | 28 KB | Viable — covered and under budget |
| Font B | 100% | 52 KB | Reject — over the 35 KB budget |
| Font C | 62% | 19 KB | Reject — cheap but won't render Polish accents |
| Font D | 100% | 31 KB | Viable — covered, tight; decide A vs D on brand |
Cookbook
Selection scenarios where one lens alone would have given the wrong answer. Coverage numbers come from the character coverage map; size numbers are projections from this analyser. For the procurement-budget angle specifically, see glyph budget planning.
Small font that secretly can't do the job
ExampleFont C was the smallest candidate and the team nearly picked it on size alone. The coverage map showed only 62% of Latin Extended — it was missing the ogonek and caron accents Polish and Czech need. Size lens said yes; fitness lens said no.
Glyph count (size lens): Latin Extended projection: 19 KB -> cheapest candidate Coverage map (fitness lens), 346 blocks: Latin Extended-A: 62% covered -> missing U+0105 ą, U+010D č, U+0119 ę ... Verdict: rejected. Polish would render with tofu/fallback glyphs.
Well-covered font that's too heavy
ExampleFont B covered every required block at 100% and looked great, but projected 52 KB at the Latin Extended subset against a 35 KB budget. Fitness lens said yes; size lens said no. Rejected.
Coverage map: Latin Extended 100% -> passes fitness Glyph count: Latin Extended projects 52 KB -> 17 KB over budget The full font is ~140 KB (CFF, 2 stylistic sets bloating it). Even subset, it can't hit 35 KB. Rejected on cost.
The analyser's subset count is not a coverage score
ExampleA reviewer read the analyser's Latin Extended glyph_count as 'coverage' and assumed a high number meant full Polish support. It doesn't — glyph_count just counts codepoints inside the range, and a font can have many of them while still missing specific required accents. Always confirm fitness with the coverage map.
Glyph count analyser: Latin Extended glyph_count: 280 (looks high!) But Latin Extended-A is 0x0100-0x017F (128 codepoints) and the range walked is 0x0100-0x024F + 0x1E00-0x1EFF (608). 280 inside that range can still MISS the specific Polish set. Use coverage map per-block %, not glyph_count, for fitness.
One-minute go/no-go per candidate
ExampleThe full screen for one font: two uploads, two reads, one verdict. Repeat per candidate, then rank survivors.
Candidate: Aria-Regular.woff2 1. coverage-map -> Latin Basic 100%, Latin Ext 100%, € present 2. glyph-count -> Latin Ext subset projects 27 KB 3. budget = 35 KB -> 27 < 35 Verdict: VIABLE. Add to shortlist. Total time: ~60 seconds, no font editor, no build.
Automate the comparison into one report
ExampleBoth tools run via the runner API. Loop your candidates, capture size from the analyser and coverage from the map, and emit one table for human review.
for f in candidates/*.woff2; do
SIZE=$(curl -sS -X POST \
http://127.0.0.1:9789/v1/tools/glyph-count-analyzer/run \
-F "files=@$f" | jq '.projections[]
| select(.subset|startswith("Latin Extended"))
| .estimated_woff2_bytes')
COV=$(curl -sS -X POST \
http://127.0.0.1:9789/v1/tools/character-coverage-map/run \
-F "files=@$f") # HTML; grep the Latin Extended block %
echo "$f size=$SIZE coverage=..."
doneEdge 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.
Treating the analyser's glyph_count as a coverage score
MisreadThe analyser's per-subset glyph_count counts how many codepoints fall inside a subset's range — it does not tell you whether the specific characters a language needs are present. A font can have 280 codepoints inside the Latin Extended range and still be missing the exact Polish or Czech accents. For language fitness, read the coverage map's per-block percentage, which is computed against 346 real Unicode blocks, not the analyser's six size-oriented subsets.
Coverage map says 100% but the font is huge
Expected (different axis)The coverage map only reports fitness; it says nothing about file size. A font can cover every required block at 100% and still be 140 KB after subsetting — too heavy to ship. That's not a contradiction, it's the two axes doing their separate jobs. Always run the analyser too; coverage alone has gotten teams to adopt fonts they then couldn't fit in budget.
Analyser projects tiny but the font is unfit
Expected (different axis)A small projected size means cheap, not suitable. Font C projected 19 KB and was the cheapest candidate — and couldn't render Polish. Size is necessary, not sufficient. Pair every size read with a coverage read before shortlisting; the cheapest font that fails fitness is worse than a slightly heavier one that works.
Six subsets vs 346 blocks granularity gap
By designThe analyser deliberately uses six coarse subsets because it's a size heuristic — projecting KB for the common shipping charsets. The coverage map uses the full 346-block list because fitness needs fine granularity (a language can hinge on a single block). Don't expect the analyser to tell you about, say, Devanagari or Hebrew coverage — it doesn't model those subsets at all. The coverage map does.
A required script isn't one of the six subsets
Use the coverage mapIf your requirement is Arabic, Thai, Hebrew, or any script outside Latin/Cyrillic/Greek, the analyser has no subset row for it — its projections won't help you size that script, and you'd need a custom subset. The coverage map still scores it (it covers 346 blocks). For sizing a non-Latin script, build the real subset with the font subsetter and measure the output.
Variable font: same coverage, different size story
ExpectedA variable font's coverage is identical across all its weights (one glyph set), so the coverage map gives one answer for the whole family. But the size story changes — the variable file replaces multiple statics. Use the coverage map once for fitness, then use the analyser on the variable file (and on the static instances you'd otherwise ship) to compare the size trade-off.
Glyph total inflated by features you won't use
By designTwo fonts can show very different total_glyphs purely because one bundles small caps, swashes, and figure variants. That difference is about features, not coverage or even shipping size after a feature-stripping subset. Don't rank candidates by raw glyph total — rank by coverage (fitness) and projected subset size (cost). The raw total is the noisiest of the three numbers.
Licence allows webfont but not subsetting
Out of scope (check the EULA)Neither tool reads the licence. Some foundry EULAs permit web embedding but forbid modifying or subsetting the font binary. The analyser's projection assumes you'll subset; if the licence forbids it, your real shipping size is the full font, not the projection. Confirm subsetting rights before you budget against a subset projection — a tool can measure bytes but can't read a contract.
Frequently asked questions
What's the core difference between glyph count and coverage?
Glyph count is a size lens: it projects how many KB the font ships as after subsetting to one of six fixed charsets. Coverage is a fitness lens: it scores, across 346 Unicode blocks, how much of each script the font actually supports. Glyph count answers "how expensive?"; coverage answers "will the text render?" You need both to pick a font responsibly.
Can I judge language support from the analyser's glyph_count?
No — and this is the most common mistake. glyph_count counts codepoints inside a subset's coarse range; it doesn't confirm the specific characters a language requires are present. A high count can still hide missing accents. For language support, read per-block coverage from the character coverage map, which scores against the full 346-block list.
Why does the analyser use six subsets but the coverage map uses 346 blocks?
Because they're built for different jobs. Six coarse subsets are enough to project shipping size for the common web charsets — a sizing heuristic. Fitness needs fine granularity because a single Unicode block can make or break a language, so the coverage map scores all 346 real blocks. The granularity gap is intentional, not a limitation of one or the other.
Which tool do I run first?
Coverage first. If a font can't render your required scripts, its size is irrelevant — eliminate it immediately. Once a font passes the fitness screen, run the glyph count analyser to check it fits your byte budget. Running size first risks falling in love with a cheap font that turns out to be unfit.
Can two fonts have the same glyph count but different coverage?
Easily. One font might spend its glyphs on small caps, ligatures, and figure variants for Latin; another spends the same count adding Cyrillic and Greek. Same total, very different coverage. That's exactly why raw glyph total is a poor selection criterion — use coverage for fitness and projected subset size for cost instead.
How do I build a reusable selection checklist from these two tools?
Document the requirement (languages + symbols), then for each candidate record: required-block coverage from the coverage map, smallest covering subset, and that subset's projected KB from the analyser. Viable = all required blocks ~100% and projected size under budget. Pin the checklist in the design system so every future font decision uses the same objective screens before brand judgement.
What if my required script isn't one of the analyser's six subsets?
Then the analyser can't size it directly — there's no Arabic, Thai, or Hebrew subset row. Use the coverage map to confirm fitness (it scores those blocks), then build the actual subset for that script with the font subsetter and read the real output size. The six-subset projection is a Latin-script-centric sizing shortcut.
Does a smaller font ever beat a better-covered one?
Only if both pass the fitness screen. Among fonts that all cover your required scripts at ~100%, the smaller projected size wins on performance. But a smaller font that fails coverage isn't a contender at all — coverage is a gate, size is a tiebreaker among those that pass the gate.
Can I automate the two-lens comparison?
Yes. Both tools expose the runner API: POST each candidate to glyph-count-analyzer/run for size and character-coverage-map/run for coverage, then emit one comparison table. Schemas are empty, so you just send the file. This turns a manual screen into a repeatable candidate-ranking report — useful when evaluating a dozen foundry options.
Do these tools read the font's licence?
No. Neither tool inspects EULA terms. Some licences permit web embedding but forbid subsetting the binary — in which case the analyser's subset projection doesn't reflect what you can legally ship. Always confirm subsetting and embedding rights separately; the tools measure the font, not the contract.
How long does a full two-lens screen take?
About a minute per candidate: two uploads, two reads, one verdict. Coverage gives a pass/fail on fitness; glyph count gives a pass/fail on budget. For a shortlist of five to ten fonts that's well under fifteen minutes of objective screening before you bring in subjective brand and licence factors.
Are both tools private?
Yes. Both parse the font in your browser via WebAssembly — nothing is uploaded. Only an anonymous processed-file counter is recorded for dashboard stats, with no font content, and it's opt-out. You can evaluate confidential or pre-release fonts on both lenses without exposing the binary.
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.