Web font formats and subsetting: WOFF2 done properly

What TTF, OTF and WOFF2 actually are

TTF and OTF are two flavours of the same container. Both are SFNT files: a directory of tables such asglyf, cmap, hmtx and GSUB laid out one after another. The difference is how the outlines are stored. TrueType uses quadratic B-splines kept in the glyftable, while the OpenType CFF flavour uses cubic Bézier curves kept in a CFF orCFF2 table. On screen the distinction is invisible; both sit inside the file structure the OpenType specification defines.

The real difference is compression, and neither format has any. They were designed for desktop use and carry the data verbatim. WOFF2 is not a new outline format: it is a wrapper around the same SFNT tables that does two things. First it applies a reversible transform to the glyf and loca tables that rewrites point data into a form that compresses better, then it compresses the whole body with Brotli. The browser reverses the transform after download and ends up with an ordinary OpenType font.

So the answer to "does WOFF2 degrade the font" is no. The transform is lossless and not one control point moves. WOFF 1.0 used zlib; the combination of Brotli plus the glyph transform makes WOFF2 noticeably smaller for the same source font. If you ship one format for the web, ship WOFF2: every current desktop and mobile browser reads it. Listing TTF as a fallback mostly buys you the risk of downloading the same font twice when the src order is wrong.

Subsetting is where the size actually goes

Font size tracks glyph count more than anything else. A family that covers Latin, Cyrillic, Greek and the extended punctuation carries thousands of glyphs, and a typical interface uses a small fraction of them. Subsetting removes the glyphs you never draw along with their cmap, kern andGSUB entries. Moving to WOFF2 buys you something in the region of thirty per cent; a well chosen subset can cut the same font by a multiple. The order matters: subset first, then convert to WOFF2.

Where a Latin-only subset breaks

The common mistake is deciding that "the Latin range is enough" and stopping at Latin-1. For Turkish that loses half the alphabet's special characters. ç (U+00E7), ö (U+00F6) and ü (U+00FC) live in Latin-1 Supplement, but dotless ı (U+0131), dotted capital İ (U+0130), ğ (U+011F), Ğ (U+011E), ş (U+015F) and Ş (U+015E) sit in Latin Extended-A, the block from U+0100 to U+017F. A Latin-1 subset drops them.

The failure is quiet. The browser draws the missing characters from a fallback font, so a word like "ışık" renders as a mix of two typefaces, advance widths stop matching and line breaking shifts. The text stays readable, which is exactly why nobody notices until a user sends a screenshot. We hit this on another site and the test has been in the checklist ever since: put the stringığĞŞşçÇöÖüÜİ on a real page and look for characters that fall back.

On Google Fonts the split shows up as the latin and latin-ext subsets, and Turkish needs latin-ext. If you build subsets yourself, include the whole U+0100-U+017F block rather than listing individual characters: brand names, quotations and user-generated content eventually pull in another letter from the same block. To find out which characters a body of copy actually uses, flatten it with the text cleaner and skim it in the word counter before you cut anything.

A second trap: text-transform: uppercase on Turkish text needs lang="tr"to map i to İ. Without the language tag the browser produces I instead, your font never draws İ, and the missing glyph stays hidden until a name that starts with İ shows up.

unicode-range and split subsets

Instead of one large subset you can split the font into several files and give each anunicode-range. The browser scans the characters on the page and downloads only the@font-face rules whose range intersects them, so a Turkish page never fetches the Cyrillic file.

Two details decide whether this pays off. Matching happens per file, not per character: a single ğ anywhere on the page pulls the entire Latin Extended-A file. For a site that is Turkish throughout, one merged file often beats a latin plus latin-ext split, because you trade two requests for one. And when ranges overlap, declaration order starts to matter, so it is worth writing the ranges so they do not intersect. The CSS formatter helps keep long @font-face blocks readable while you do it.

font-display: choosing between FOIT and FOUT

While a font downloads the browser has two options: draw nothing, or draw with a fallback and swap later. The first is FOIT, a flash of invisible text; the second is FOUT, a flash of unstyled text. Thefont-display descriptor controls this with two windows: during the block period the text is invisible, during the swap period it is drawn with the fallback and replaced if the font arrives.

• block: a short block period then an unlimited swap period. For text that must never appear in the wrong face.
• swap: an almost zero block period and an unlimited swap period. Text appears immediately and is replaced later. A sensible default for body copy.
• fallback: a very short block period and a short swap period. If the font is late you keep the fallback and avoid a jarring late swap.
• optional: a very short block period and no swap. The browser may decide not to use the font at all, so a first visit on a slow connection stays on the fallback.

The cost of FOUT is layout shift: if the fallback and the real font have different advance widths, lines jump when the swap happens. The fix is not to disable swapping but to bring the fallback closer to the real font. The size-adjust, ascent-override and descent-override descriptors on a local fallback @font-face exist for exactly this.

When preloading helps

A web font is discovered in two steps: the browser downloads the stylesheet, finds the@font-face rule, and only requests the file once an element that needs it is laid out. That chain is the main reason fonts land late. A<link rel="preload" as="font" type="font/woff2" crossorigin>shortens it.

Two rules apply. The crossorigin attribute is required even when the file is on your own origin, because fonts are fetched in anonymous CORS mode; leave it off and the browser downloads the same file twice. And preloading is a priority tool, so promoting everything promotes nothing. Keep it to the one or two faces that are genuinely visible in the first viewport.

When a variable font wins

A variable font carries axes such as weight or width in a single file. It is larger than one static instance but usually smaller than four of them. The break-even point sits somewhere around two to three weights: with regular and bold only, two static files are likely lighter, while from three weights up the variable version pulls ahead. You can also subset a variable font and drop axes you never vary.

Drive the weight through font-weight rather than font-variation-settings. Declaringfont-weight: 100 900 in the @font-face rule and using ordinaryfont-weight values in your CSS keeps the browser's own matching and synthetic bolding logic working correctly.

Licensing, the part people get wrong

A desktop licence lets you install the font and produce documents with it. Converting the same file to WOFF2 and serving it from a web server is a different use, and most commercial foundries sell it separately, priced by domain or by monthly pageviews. "I ran it through a converter, so the format changed" is not an argument the licence text recognises.

Families released under the SIL Open Font License remove the problem: web use, subsetting and modification are all permitted. Two conditions come with that. You may not sell the font files on their own, and if the licence marks a Reserved Font Name you may not keep that name on a modified version. Subsetting is technically a modification, so if you distribute the output under the original name, ship the licence text alongside it.

Self-hosting has a privacy dividend as well: every request to a third-party font host hands that service the visitor's IP address. The performance argument usually points the same way, since you drop a connection to an extra origin.

The short version

1. Confirm the licence covers web use before anything else.
2. Do not stop the subset at Latin-1; include U+0100-U+017F.
3. Convert the subset to WOFF2 and ship nothing else.
4. Use font-display: swap for body copy and align the fallback with size-adjust.
5. Preload the single first-viewport face, with crossorigin.
6. Test the string ığĞŞşçÇöÖüÜİ on a real page before release.

Platform "fonts" are not fonts

Everything above is about a file the browser downloads and the shapes it draws. The stylised writing you see in game names and social media profiles works the other way round: nothing is downloaded at all. Unicode contains blocks such as the mathematical alphanumerics, enclosed letters and fullwidth forms, which hold separate code points that happen to look like an A, and the effect comes from writing one of those instead of a plain A.

The page names understate this. Roblox fonts and Adopt Me fonts do not produce a font file; they swap characters. A game ships its own typeface inside its own bundle and will not load one from outside, so the only thing you can change is which characters you type. The same holds for the Instagram, Discord and Twitter pages.

Two consequences follow. If you want an interface to genuinely render in another typeface, the route is the one described above: publish a subsetted WOFF2. If you want to decorate a username, you are changing characters rather than fonts, and the cost is legibility, because screen readers will not announce those code points as letters and search engines cannot match the word. The general-purpose equivalents live in Unicode text styles and Unicode symbols. Where this helps and where it backfires in game names is covered separately in stylised game fonts and Unicode.