Lesson 11·Unit 4 · Scripts and layout·Font stacks & glyph coverage·Lv 201·~7 min

CJK font fallback & character coverage

Your 'pure sans-serif' headline silently switches to the OS default for one Hanzi character, and the OS default is different on macOS, Windows, Android, and iOS. A Japanese user gets the Chinese glyph variant. A Chinese user gets the Japanese one. Both are wrong.

fontfallbackOS-specific

By the end

·Explain Han unification: one code point, several regionally correct shapes, and the font picking between them.
·Predict what a browser does when a font lacks a glyph: fall down the stack character by character, landing on an OS default.
·Say what lang="ja" changes for a unified code point, and why a CJK launch needs a font stack per script.

The problem

CJK Unified Ideographs share codepoints across Chinese, Japanese, and Korean, but the canonical glyph shapes differ. If your font stack doesn't include a script-specific CJK font, the browser falls back to the OS default, which often picks the wrong regional variant. Native speakers notice immediately and read it as a sign that you didn't take the locale seriously. Worse: the rendering differs between platforms, so QA on macOS won't catch what an Android user sees.

How it works

A font stack is a negotiation, one glyph at a time

font-family does not mean "use the first font". It means "for each character, use the first font in the list that has a glyph for it". Your Latin headline face almost certainly contains no CJK glyphs. For those characters the browser walks past your whole stack and lands on an OS default, typically a different font on every platform. Nothing errors. One headline quietly mixes two or three fonts, with different metrics on each machine.

The larger issue is Han unification: Unicode assigns one code point to a character that Chinese and Japanese conventions draw differently. 直 (U+76F4) is the classic example. The code point cannot tell the font which shape a reader expects. Only the language can. That is the concrete job of the lang attribute: it steers font selection and glyph conventions for unified code points, and it also feeds line-breaking and assistive tech. Tag the page, and tag every span that switches language.

See it yourself

Try these, in order

Each step triggers a specific failure you should recognize on sight.

1
On the default mixed sample, compare the “Naive (Helvetica/Arial)” row against the Noto row. The naive stack still renders CJK: the OS silently substituted a system font. Expand the per-font availability list to see which fonts exist on your machine.
2
Switch the sample to “Traditional Han characters”. 説 vs 说: watch which stacks render the traditional form with correct glyph conventions, and which fall back to a simplified-leaning font.
3
Compare the measured pixel widths listed for each stack. The same string measures differently per stack. Silent fallback shifts layout and truncation behavior per platform, in addition to the letterform change.
4
Compare the “N of M fonts available on this device” line across the five stacks. The counts are a property of this machine, not of the page. On another OS the same stacks produce different availability lists, substitutes, and rendering: the bug class that never reproduces on the reporter's machine.

Sample text

The Han-trad / Han-simp samples look nearly identical in many stacks. Watch for this subtle bug when you ship zh-Hans only.

Naive: Helvetica only0 of 2 fonts available on this device (approximate)