Font Coverage Checker

Try the Checker

Why Coverage Gaps Hide Until Launch

A font that renders English perfectly can be missing a single accented character your German page needs. Browsers never complain; they silently swap in a fallback face for that one glyph, and suddenly a heading is part Inter and part Times New Roman. The visual break is small in isolation and jarring in a hero title, where the mismatch sits in the largest text on the page.

The classic failure is testing in one language. Teams design in English, check the font in English, and ship the localization with the same family list. The Polish, Czech, and Vietnamese pages are the ones that expose the gaps, often weeks after launch, when someone finally looks closely at a translated headline. Coverage checking is a five-minute pass that belongs in the same review as contrast and line length.

The stakes are higher than aesthetics in accessibility reviews. A missing glyph that falls back to a system face can change the perceived weight and size of a label, and the screen reader experience does not change at all, the text is still read aloud correctly. But for sighted users the inconsistency reads as broken styling, which erodes trust in the page faster than any other single typographic defect.

How the Two Passes Work

The instant pass needs no network. Each character in your text is classified into one of the groups the catalog records: latin, latin-ext for western European accents, Cyrillic, Greek, and Vietnamese. A font scores for every character whose group appears in its declared subsets. Because the metadata sits in the catalog, the ranking renders the moment you paste.

The verify pass trades the metadata for ground truth. For each of the 38 families it asks the Google Fonts CSS API for a stylesheet built from exactly your characters. The API returns unicode ranges for the glyphs the font genuinely contains, and the tool parses those ranges to compute the exact coverage, character by character. A font that lacks one rare accent shows a 96 percent score instead of a clean 100.

The two numbers are shown side by side when they disagree, which is itself useful signal: a font whose metadata promises more than its glyphs deliver is worth treating with caution. The verify pass makes about 38 lightweight stylesheet requests and then stops; nothing is installed and no font binaries are downloaded to your machine.

The Character Groups the Catalog Tracks

Latin covers the basic alphabet plus common punctuation, and every family in the catalog supports it. Latin-ext adds the western European accents: the cedillas, tildes, and diacritics of French, German, Spanish, Polish, and Turkish. A font that lists latin-ext handles the vast majority of European copy, but the coverage is not uniform, which is why the verify pass exists.

Cyrillic and Greek are the second tier. Fewer families carry them, and the ones that do were usually designed with those scripts from the start rather than bolted on later. Vietnamese is the subtle case: its precomposed letters look like latin accents but live in their own Unicode ranges, so a font can cover French perfectly and stumble on Vietnamese. Everything else, emoji and CJK and Arabic and the rest, is beyond the catalog, and the checker says so instead of pretending a score exists.

How to Use the Checker

1. Paste real copy from every locale you ship. Headline text matters most, because display sizes expose fallback mismatches first.
2. Read the instant ranking for a first cut: the fonts at the top support the languages your text uses.
3. Run the verify pass to confirm the top candidates carry every character, not just the declared subsets.
4. Click a font name to open its page in the catalog and check its weights and pairings before committing.
5. Record the choice in your design tokens with a note about which locales it was tested against.

Common Coverage Assumptions That Fail

The most common assumption is that all sans-serifs cover the same characters. They do not. The catalog shows families with near-identical latin coverage that diverge completely on Cyrillic, and a font choice made for one market can lock out another.

The second is equating language name with character set. Vietnamese looks like latin to the eye, but its precomposed letters live in dedicated Unicode ranges that a latin-ext font may skip. The classifier in this tool treats Vietnamese as its own group precisely because of that trap.

The third is assuming the font file you serve is the font whose coverage you measured. Google Fonts serves subset files by unicode range, so the browser downloads only the pieces your page uses. The coverage question is about the family as a whole, and the answer holds for the served subsets, which is what the verify pass reads.

Where This Fits with the Other Tools

Coverage is a gate on the same path as the other checks. The pairings library narrows the candidates by mood and use case, this tool narrows them by language, and the contrast checker verifies legibility on the ones that remain. The fallback previewer shows what happens when a missing glyph does slip through, and the typography playground is where the chosen family gets tested against real multilingual copy.

FAQ

What does font coverage mean?

Coverage is the set of characters a font can render. Every font ships with a subset of the full Unicode range: most cover basic latin, many add latin-ext for western European accents, and fewer still include Cyrillic, Greek, or Vietnamese. When a font lacks a character, the browser substitutes a fallback face, and the mismatch in style is immediately visible.

How does the verification against Google Fonts work?

The verify button asks the Google Fonts CSS API for each family with the text parameter set to your exact characters. The API answers with a stylesheet that lists unicode ranges only for the glyphs the font actually has. The tool parses those ranges and marks precisely which characters each family covers, with no font files downloaded to your machine.

Why does the subset ranking differ from the verified result?

The subset field in the catalog is the language metadata a font declares, which is usually but not always the full truth. A font may declare latin-ext support yet miss a rare accent, or cover a character the metadata does not mention. The verified pass reads the actual glyph ranges, so it is the ground truth.

What happens to characters no catalog font covers?

Emoji, CJK, Arabic, and other scripts outside the catalog fall into the other bucket and are excluded from the ranking, because every font in the library would score zero on them. If your text needs those scripts, the answer is a script-specific font, not one of these families.

Does coverage affect page performance?

Indirectly. Google Fonts subsets each family on request, and browsers download only the glyphs in the unicode ranges the page uses. A font that covers your text in one language request serves smaller files than a full-coverage download. Choosing a font whose coverage matches your content keeps the payload lean.

Should I check coverage before picking a font for a site?

Yes, and it is cheap to do. Localization teams discover coverage gaps after launch, when headings suddenly render in a fallback font. Running the text of every locale through this checker during the pairing pass, next to the contrast and readability checks, catches the gap before it reaches production.