If you run a global product with a Japanese site, there's a decent chance it looks subtly wrong — and nobody has told you. Not because your team is careless, but because of a 30-year-old design decision in Unicode, and because the people who notice have no way to reach you.
I scanned the Japanese pages of 201 candidate sites with a tool I built, and successfully measured 146 (109 global brands, plus 37 Japanese companies as a control group). I found four different ways Japanese typography quietly breaks — including five brands where it's broken for every visitor, right now, and where most of the cause wasn't even in their own CSS.
The 30-second background: Han Unification
Japanese and Chinese share thousands of characters — but write many of them differently. The character 直 ("direct") has a different skeleton in Japanese and Simplified Chinese. Unicode assigned both the same code point and delegated the visual difference to fonts. Same HTML, same bytes: whether it renders Japanese or Chinese depends entirely on which font the text lands on.
If your CSS declares no Japanese font family, you didn't decide how your Japanese text looks. The visitor's device did. And if your CSS declares a Chinese font — it's worse.
Methodology (and two bugs I caught in my own tool)
- 201 candidate sites listed mechanically by category prominence — no site added or removed based on expected results. Every site has an official Japanese-language page, meaning every one of these companies already decided Japan matters enough to translate for.
- Top pages only, single pass, 2026-08-18, scanner v1.0 (measurement conditions frozen at publication).
- Environment A: headless Chromium with Japanese fonts (a Japanese-locale device). Environment B: identical but no Japanese fonts — only Simplified Chinese (most Linux boxes, many non-Japanese-locale devices, and almost every server that renders your OG images and PDFs).
- 2 sites disallowed us via robots.txt, 26 blocked the crawler (it identifies itself as GlyphChecker and complies), 27 had no reachable Japanese page or errored. Yes, this skews the sample toward less-defended sites; I report it rather than hide it.
- 52 sites were scanned on independent passes: every core metric reproduced within 2 points.
- I also found and fixed two false-positive bugs in my own scanner before publishing: one where the test environment flagged "mixed fonts" that real browsers on real machines don't produce (verified on Chrome, Edge and Firefox on stock Windows), and one where the Chinese-font detection fired on stacks that resolve safely on every current OS. The numbers below survived both corrections. n=146 is still too small for decimal precision — read "roughly half," "two in three."
Finding 1: five brands serve Chinese fonts to everyone — and most can't see why
This is the one with no excuses attached. On 5 of the 109 global brands (0 of 37 Japanese companies), the CSS names a Chinese font — Microsoft YaHei, PingFang SC, Noto Sans TC — ahead of any Japanese font, or with no Japanese font at all. Every visitor whose device has that font (which includes stock Windows and/or macOS, depending on the stack) sees Japanese text drawn with Chinese glyph shapes. Right now. No locale settings, no unusual devices, no excuses.
The five: a robot-vacuum maker, a drone maker, a productivity SaaS, a game publisher, and a travel platform. I'm not naming them, because here's the part that matters more: for three of the five, the Chinese font isn't in their own stylesheets. It ships inside third-party widgets — a widely-deployed cookie-consent banner and a live-chat tool — whose font stacks list Chinese fonts before Japanese ones. Every site that embeds those widgets inherits the bug. Their developers could audit their own CSS forever and never find it.
One vendor fixing one line would fix this across every site that embeds them. That's the strange economics of supply-chain typography.
Finding 2: the real gap is one line of CSS
81% of the Japanese companies I measured declare Japanese font families in their CSS. Among global brands: 42%. That single line is the difference between "renders with the OS's Japanese fonts wherever they exist" and "renders with whatever the device coughs up." Its absence is what produces the next finding: on devices without Japanese fonts, 55% of global brands garble with no declared fallback at all (Japanese companies: 5%).
It isn't budget. Web font serving is low on both sides — roughly three in ten, global or Japanese. Japanese teams don't serve more fonts; they write one more line.
Finding 3: on devices without Japanese fonts, 87% turn Chinese
In Environment B, 87% of global brands' pages (and 57% of Japanese companies') rendered Japanese text with Chinese-style glyphs.
Who actually sees this? Honest answer: not the average Japanese consumer on a Japanese-locale phone — and since March 2025, Windows even ships Noto CJK fonts as protected system fonts, so stock devices keep getting safer. But "devices without Japanese fonts" still includes: Linux machines, English-locale corporate laptops, expats on locally-bought devices, Chinese-speaking residents and visitors in Japan who can read the glyph difference — and, critically, the render farms: the headless browsers and PDF engines that generate your OG images, receipts, and email snapshots. Those artifacts get delivered to Japanese-locale screens looking Chinese, no matter how good the recipient's device is.
Supplementary finding: the patchwork
63% of global brands (8% of Japanese companies) render Latin and Japanese inside the same sentence in unrelated fonts — "70g" in Arial, the rest in whatever the device provides. It's visible on stock devices today, though subtle; to Japanese eyes it reads less as "broken" and more as "nobody is minding the details." (This number is after removing a measurement artifact that inflated it — see methodology.)
Why does any of this read as "cheap" rather than merely "wrong"? Mismatch itself is a universal signal — a Chinese site set in Chinese fonts looks perfectly trustworthy; the problem is text wearing another language's conventions. And in Japan specifically, consumers have spent two decades seeing broken Japanese typography in a very particular corpus: scam shopping sites, machine-translated spam, counterfeit packaging. Mangled glyphs pattern-match to that corpus before your product gets a chance to speak.
The fix (3 lines of effort)
-
<html lang="ja">— tells text engines which glyph variant to pick. (~92–100% of scanned sites already do this. Necessary, not sufficient.) - Declare Japanese families —
font-family: "Noto Sans JP", "Hiragino Sans", "Yu Gothic", sans-serif;— and make sure no Chinese font name precedes them, including inside third-party widgets you embed. - Serve a Japanese web font (a subset is ~tens of KB with
unicode-range— the same mechanism Google Fonts uses). The only fix that removes the visitor's device from the equation entirely, and the only one that saves your server-generated images and PDFs.
Check your own site
The scanner from this study is free: glyphchecker.com — paste a URL, get side-by-side screenshots of your page with and without Japanese fonts, a check for Chinese font declarations (including third-party widgets), and the exact CSS to fix what it finds.
One thing to know before you try it: if your machine has Japanese fonts installed, the breakage is invisible to you by definition — that asymmetry is what this whole article is about. The scanner renders your page in an environment without them and shows you the diff.
The sites that scored 100/100 didn't spend more money. They wrote one more line of CSS.
A note on language: I'm a Japanese developer, and English isn't my strong suit. The research, the scanning, the debugging and the conclusions are mine; an AI helped me write them in English I can't fully verify myself. If a sentence reads oddly, that's the exact phenomenon this article is about — text crossing a language barrier without a native eye on the other side.
Top comments (0)