What unicode-range does for performance
unicode-range is a CSS descriptor inside @font-face that limits when the browser downloads a font. With unicode-range: U+0000-00FF declared on the Latin subset, the browser only fetches the font file if the page contains a character in that range. Cyrillic, Greek, and CJK subsets are skipped entirely. The result is that a Latin-only page downloads one small file instead of the full multi-script family.
Google Fonts splits every font into roughly 10 to 20 unicode-range subsets behind the scenes. When you embed a Google Font, the browser only downloads the subsets your page actually uses. Self-hosting can achieve the same result if you build the @font-face blocks with the right unicode-range values. The Preview tool tells you which ranges your font actually covers, so you know which to declare.
How the Preview parses your font
Drop a TTF, OTF, or WOFF2 file into the Preview and it parses the font cmap table directly in the browser using opentype.js. The cmap table maps Unicode code points to glyph indices inside the font. The Preview walks every code point in the table and groups them into the standard Unicode blocks: Basic Latin, Latin-1 Supplement, Greek and Coptic, Cyrillic, and so on.
Each block reports a coverage percentage: what fraction of code points in that block your font actually has glyphs for. A font that covers 100 percent of Basic Latin and 78 percent of Cyrillic tells you, at a glance, that Cyrillic is partial and you may want a fallback. Hover over any glyph in the grid view to see the code point and the glyph name.
Common Use Cases
Performance engineers self-hosting Google Fonts use the Preview to find the exact unicode-range values that match their font file, then ship a single @font-face block per subset. Designers picking a brand font use the Preview to confirm coverage of the languages they need before signing a license. Developers debugging missing glyphs use the Preview to see whether the font ships them at all (versus the rendering pipeline silently substituting from a fallback).
i18n teams use the Preview to vet new fonts against a coverage matrix: does this font cover Vietnamese, Polish accents, or full IPA. The grid view lets you scan a block and spot gaps that a percentage number would hide.
How We Compare
Online font subsetters like Glyphhanger and pyftsubset are excellent for actually slicing the font file but require command-line setup. The Preview is for the step before that: deciding what to subset. Once you know your font has full Latin and partial Cyrillic, you can choose whether to keep both subsets or drop Cyrillic.
Compared to opening a font in FontForge or Glyphs, the Preview is purpose-built for the web workflow: it outputs unicode-range CSS directly. No font-engineering knowledge needed.
Frequently Asked Questions
What file formats are supported?
TTF, OTF, and WOFF. WOFF2 is supported once you decompress it first because Brotli is required and the opentype.js library can include a decompressor. The Preview detects the format from the file magic bytes and parses accordingly. EOT, the Microsoft legacy format, is not supported because no modern browser still needs it.
Why are some fonts marked as having partial coverage?
A font has partial coverage of a Unicode block when it includes glyphs for some code points in that block but not all. For example, a font might cover U+0041 through U+007A (basic Latin letters) but not U+0021 (exclamation mark). The Preview shows which specific code points are missing inside each block so you can decide whether the gaps matter for your use case.
What is the difference between a Unicode block and a unicode-range?
Unicode blocks are the standardized groupings defined by Unicode itself: Basic Latin, Cyrillic, Greek, etc. unicode-range is a CSS descriptor that accepts any arbitrary set of code points. The Preview groups results by Unicode block because that maps cleanly to typical font subsetting needs, but you can override the auto-generated unicode-range to add or remove specific code points.
Are variable axes also reported alongside glyph coverage?
Yes. Variable fonts have the same cmap table as static fonts, so coverage is identical across all axes. The Preview reads the cmap once and reports the same coverage regardless of which variable instance you would render with. The Preview also reports the count and names of the variable axes (wght, wdth, opsz, etc.) as a bonus.
Can I export the subset list as JSON?
Yes. Below the visual report there is an Export JSON button that produces a structured object listing every block, the code point range, the coverage percentage, and the specific missing code points. This is useful for automated CI checks or for input to a subsetting build step.
Will the font I upload be sent anywhere?
No. The font is parsed entirely in your browser using JavaScript. The file never leaves your machine. The Preview works offline once the page is loaded. This matters because licensed commercial fonts often have terms that prohibit uploading them to third-party servers, and the Preview respects that by never doing so.
How accurate is the coverage percentage?
Exact. The Preview counts the code points in each Unicode block that have a non-null glyph mapping in the font cmap table, divides by the total code points defined in that block by the Unicode standard, and rounds to one decimal place. If a glyph is mapped but rendered as .notdef (the empty box), the Preview detects that and excludes it from the count.
Can I generate the unicode-range CSS for self-hosting Google Fonts?
Yes, and this is the most common use case. Google Fonts uses standardized unicode-range values for its subsets: Latin is U+0000-00FF U+0131 U+0152-0153 U+02BB-02BC and so on. The Preview detects when your font matches one of these standard subsets and offers to emit the matching Google-style unicode-range string, ready to paste into your @font-face block.