A Japanese name displays as an empty box, blank square, or "tofu (豆腐)" placeholder when the web font loaded on the page is a subset font that only bundles the few thousand most common Han characters, so any character outside that subset (frequently found in surnames) has no matching glyph to render. The fix is a coverage check against the actual name strings you need to display, not a general font swap.
Why Do Japanese Characters Show as Boxes or Blank Squares?#
A box or blank square is the browser's fallback glyph, shown when the active font file contains no drawing for the character code the page is asking it to render. This is a font-file problem, not a text-encoding problem: the underlying Unicode character is almost always correct, but the specific web font linked in the page's CSS never shipped a glyph for it. Font engineers have a nickname for the placeholder itself: "tofu (豆腐)," after its resemblance to a block of tofu on screen.
The failure is easy to miss during development because the team testing the site rarely tests with the actual client or partner name that will eventually appear. A generic Japanese sample string like "こんにちは (hello)" renders fine in almost any font, because greetings use only the most common characters. The gap only surfaces once a real surname or company name enters a form field, a contract PDF, or a case-study page, often after launch.
What Is a "Subset" Web Font, and Why Does It Skip Rare Characters?#
A subset font is a font file deliberately trimmed to a smaller character list to reduce file size and speed up page load, and the trim is nearly always drawn from the most statistically common characters, not from the full character repertoire a name might need. Many free and freemium Japanese display fonts subset aggressively because a full Japanese font, covering the working character set plus common variants, can run to tens of megabytes; a subset built around the highest-frequency few thousand characters cuts that dramatically.
The reference point for "common" character coverage is the Japanese Industrial Standards (日本産業規格, JIS) character sets, specifically JIS X 0208 and its later extension JIS X 0213. JIS X 0208 defines a working set of everyday kanji split into two frequency-ranked levels; JIS X 0213 extends that set with additional characters, including many used specifically in personal and place names that fall outside daily-use vocabulary. A font that only covers JIS X 0208 level 1 will render ordinary business Japanese without issue and still fail on a meaningful share of real surnames.
For a font built for professional Japanese typesetting rather than web display, the relevant coverage concept is the Adobe-Japan1 character collection, a glyph-set standard used to define what a CID-keyed Japanese OpenType font must include. Adobe-Japan1 is structured in expanding tiers, each tier adding thousands more glyphs beyond the previous one, moving from common daily-use kanji up through rare variant forms used almost exclusively in personal names. A font vendor's marketing copy rarely states which tier it covers, which is exactly why coverage has to be tested directly rather than assumed from the font's category or price point.
Which Kanji Are Most Likely to Break a Subset Font?#
The characters that break subset fonts are almost never the ones a design team thinks to test: they are variant kanji forms (異体字, itaiji), alternate historical or regional shapes of a character that carries the same meaning and pronunciation as a more common form but a different, unmerged code point. Japanese surnames are the single most common place these appear, because family registries preserve the exact historical form a family has used for generations rather than normalizing it to the modern common form.
Two frequently cited examples illustrate the pattern clearly. The character for "high," most often written 高, has a taller, ladder-topped variant form (髙) that appears in a meaningful share of Takahashi-family surnames and is a distinct Unicode code point, not a stylistic choice a font can substitute automatically. The character for "cape" or "point" in place-derived surnames like Yamazaki, most often written 崎, has a variant form (﨑) built from a different radical arrangement that likewise requires its own glyph. Related to this, some systems refer to characters missing from a given standard character set as non-standard characters (外字, gaiji), a term that predates Unicode and originally described custom, locally-encoded glyphs added outside any shared standard.
A related concept worth understanding when designing for Japanese, Simplified Chinese, and Traditional Chinese in the same layout is that character-set gaps are per-script and per-font: a font can have excellent Traditional Chinese coverage and thin Japanese variant coverage, or the reverse, because the two markets' naming conventions draw on different long-tail characters.
Key points:
(a) A missing glyph is a font-file coverage gap, not a text-encoding bug; the character code is correct, the font simply never shipped a drawing for it. (b) Coverage gaps concentrate in personal and place names, specifically variant kanji forms (異体字) that fall outside the common-use character levels defined by JIS X 0208 and extended by JIS X 0213. (c) Font category and price are not reliable predictors of coverage; a free font can have broader coverage than a paid display font if it was built against a fuller character collection.
How Do You Check a Font's Character Coverage Before Launch?#
Check coverage by rendering the actual name strings you plan to display, sourced from real client or partner records rather than generic sample text, in every font used across the site including headings, body copy, and any PDF or image-based export path. A visual proof string should deliberately include at least one known variant-heavy surname, since generic Japanese sentences will pass in almost any font and tell you nothing about the gap that matters. This test needs to run on every distinct font file in use, because a site frequently loads one font for headings and a different one for body text, and each has its own independent coverage.
This check belongs in the same pre-launch pass that verifies font licensing terms, but it is a separate question: a font's commercial license can be fully in order for web use while its character set still excludes the exact name a client-facing page needs to show. Coverage and licensing fail independently, so passing one check gives no information about the other.
Which Japanese Web Fonts Have Full Character Coverage?#
Full character coverage is available at no license cost through Google's Noto Sans JP, part of the Noto family that Google built specifically to eliminate the "no tofu" problem across scripts, and through the closely related Source Han Sans, developed jointly by Adobe and Google against a fuller tier of the Adobe-Japan1 collection. Both are engineered explicitly against broad character repertoires rather than a frequency-trimmed subset, which makes them a reasonable fallback layer even on a site whose primary display font is a narrower premium typeface.
Confirming a font sits in this category is still a "test it yourself" exercise rather than a "trust the name" one, since even broad-coverage font families ship different builds and versions over time. The safest working pattern separates the two roles: keep a narrower, more expressive font for the display type a brand is built around, and set a verified full-coverage font, such as Noto Sans JP or Source Han Sans, as the fallback in the font stack for exactly the character range the primary font does not cover.
How Do You Fix Missing Glyphs Without a Redesign?#
The fix that does not require a font swap is a CSS fallback stack: keep the brand's chosen display font first, and list a verified full-coverage Japanese font immediately after it, so the browser only reaches for the fallback glyph-by-glyph when the primary font has no drawing for that specific character. This preserves the brand's typographic choice for the overwhelming majority of the text and only substitutes silently at the exact character that would otherwise render as a box.
Where the missing character sits inside a logo, a signature graphic, or any other image-based treatment rather than live text, the practical fix is different: the character has to be re-set as a vector or high-resolution raster asset once, checked against the correct variant form, and locked into the brand asset library rather than left dependent on whatever font happens to be installed on the rendering system. This is the same asset-discipline question addressed in documenting a Japan-market brand guideline, where locked type and character treatments prevent this exact failure from resurfacing every time a new page or document gets built.
For a company preparing its Japan-market visual identity from the ground up, resolving character coverage is one part of a wider Japan-market brand identity and localization engagement, alongside color, layout density, and Latin-CJK typographic pairing decisions that all get finalized in the same brand-build pass.
Frequently Asked Questions#
Why does a name display correctly in Microsoft Word but show as a box on our website?
Word and other desktop applications typically fall back through every font installed on the operating system, which on most machines includes at least one broad-coverage system Japanese font. A website only has access to whichever web fonts the page explicitly loads, so if the CSS font stack lists only a narrow subset font with no full-coverage fallback, the browser has nowhere else to look and renders the placeholder box instead.
How do we know if a font we already licensed has this problem before it shows up in production?
Render the specific client or partner name strings you need to display in the exact font files your site loads, not a generic Japanese sample sentence, since common test phrases use only high-frequency characters that pass in almost any font. Build a short proof string that intentionally includes at least one known variant-heavy surname and check it across every distinct font used for headings, body text, and any exported PDF or image path.
Is switching to a free font like Noto Sans JP a full fix, or does the brand font need to be replaced entirely?
Switching entirely is usually unnecessary; setting a verified full-coverage font such as Noto Sans JP or Source Han Sans as a fallback in the CSS font stack, positioned after the primary brand display font, resolves the gap at the character level without changing the site's overall typographic identity. The brand font continues to render every character it supports, and the fallback is only invoked glyph-by-glyph for the specific characters it does not.
Conclusion#
Broken glyphs in a Japanese name are a font-coverage gap, traceable to a specific character falling outside the set a subset font was built against, and they are found reliably only by testing real name strings rather than generic sample text. A fallback font stack and a locked, tested brand asset library close the gap without forcing a full redesign of the site's typography.
This article is informational only and does not constitute legal, tax, or regulatory advice. Consult a qualified advisor before acting on the content. Last updated: September 2026.