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 (4)
Counting servers that render OG images and PDFs as Environment B is right, and it is the case with nobody looking at the output.
Our render container installs fonts-ipafont-gothic and fonts-wqy-zenhei side by side and ships no fontconfig ordering at all. So for a Han codepoint on a page declaring no Japanese family, whichever of the two fontconfig hands back is the output, and I have never checked which. I would assume ipafont wins on a Debian base, but assuming is the failure mode you are describing.
Does your Environment B separate the two-fonts-present case from the Japanese-missing-entirely one?
No, it doesn't. Environment B is the no-Japanese-font case, which I picked because it's deterministic: one place for the fallback to go, same result every run. Both present with no ordering never came up while I was building it, and it's worse than what I did model, since the answer isn't even stable. A base image update can flip it.
It's not ipafont, though. I ran it on a clean image just now:
Zen Hei, even with the ja hint. Both packages drop config into /etc/fonts/conf.d, and that's where it gets decided. 64-wqy-zenhei.conf aliases sans-serif to Zen Hei with no language test at all. 65-fonts-ipafont-gothic.conf does test for ja, but it uses mode="prepend", which inserts before the matched family rather than at the head of the list, so IPA lands behind Zen Hei. You're not in the "no ordering" state, two packages ordered it for you. If you want IPA to win, prepend_first with binding="strong" does it.
That's fontconfig's answer rather than Chromium's, though. For what your renderer actually did: CDP, DOM.enable + CSS.enable, then CSS.getPlatformFontsForNode on the text node. Family names with glyph counts, so you see the font that drew the pixels. Or render 直 and 込 with no font-family and look at them.
Thanks for this, by the way. "Both fonts present, no ordering" is going on the list for the next scanner version.
Finding 1 is the one I'd have led with, because it's the only one a team genuinely cannot find by looking at their own work. Three of the five, and the Chinese font is sitting inside a consent banner. Everything a front end team reviews is source: their stylesheets, their components, their tokens. An embedded widget's font stack never appears in any of that, so they can audit carefully forever and the bug stays invisible.
Cheap version of your scanner for anyone reading who wants a first look without leaving the page. Walk the DOM and collect what actually resolved, rather than reading the CSS:
The declared stack and the resolved set are different objects, and only the second one is the truth. Chat bubbles and cookie banners fall out of that list immediately.
The render farm paragraph is carrying more than its position suggests too. OG images, PDF receipts, email snapshots: that's the one surface where a good device can't save anybody, since it renders on a Linux box with no Japanese fonts and then gets delivered to a Japanese locale screen. It's also the only part of this that can be made to fail a build. Render the page in a container with the JP fonts stripped, screenshot, diff against a reference. Everything else here depends on a person noticing something, and your whole point is that the people who'd notice aren't in the room.
Going to run my own pages through it. No Japanese page on my side, but the widget finding has me suspicious about the Vietnamese one.
Thank you — that one-liner is exactly the right first check. One thing I'd add from building the scanner: the resolved set differs by device, so what you see on your machine isn't what a stock Windows or a fontless Linux box resolves. That's why I ended up rendering in controlled environments instead of trusting my own browser.
Your comment also sent me digging into Vietnamese, and you're right to be suspicious: Vietnamese has tone marks (diacritics), and many Latin webfonts simply don't include those characters — so they fall back to a different font mid-word, or the marks detach from the letters entirely. I'd thought of this as a Japanese problem, but it seems to exist all over the world in different forms. The scanner can't detect this yet, but supporting more languages is where I'd like to take it. If you run your Vietnamese pages through anything and find something interesting, I'd genuinely love to hear what you see.