Guides
Checking missing glyphs and fallbacks in web-font delivery
Verify converted or subset fonts against delivery settings and actual rendered text, including failures hidden by fallback fonts.
Which format should you choose?
Choose by the role each file plays in your workflow.
- Match font files to CSS
- Compare characters and shaping with real examples
- Check cache and local-font dependencies
Match font files to CSS
Record originals, versions, conversion settings and required characters. Check CSS family, weight and style against delivered files, URLs and cross-origin access requirements. Check usage terms for delivery, conversion and subsetting separately.
Compare characters and shaping with real examples
Test body text, input fields, dynamic content, numbers, symbols and combining characters. unicode-range declarations do not add glyphs. Check Arabic joining, ligatures, bold, italic and required variable axes in the target environment. Character coverage alone does not prove shaping quality.
Check cache and local-font dependencies
Reload at the real endpoint and inspect network retrieval and the fonts actually rendered. Check whether locally installed namesakes or fallback fonts hide delivery failures. Compare line breaks and layout before loading too; record differences before finalizing delivery.
Formats to consider
WOFF2
Good for: Delivering compressed fonts to compatible browsers
Less suitable for: Inferring the rendered font from HTTP success
TTF
Good for: Checking source fonts in compatible authoring tools
Less suitable for: Inferring coverage and shaping from the TTF extension
OTF
Good for: Checking features in compatible authoring tools
Less suitable for: Expecting every shaping feature from an OTF file
Before you export
- Keep originals, delivery copies, settings and checksums. Ensure subsetting retains characters needed by dynamic content.
- Passing tests does not guarantee display on every device or in every language. Inspect unverified fonts in a trusted testing environment.