CJK Fonts in Figma: Working with Chinese, Japanese & Korean Text

“My Chinese text shows up with slightly wrong-looking characters.” “Korean renders as empty boxes.” “The Japanese weight I picked in the browser version isn’t available.” If you design for Chinese, Japanese, or Korean audiences in Figma, you have probably hit at least one of these — and they rarely happen with Latin fonts.

CJK fonts (Chinese, Japanese, Korean) are a different category of typeface. They carry tens of thousands of glyphs, they share Unicode code points across three languages whose preferred shapes differ, and they are large enough that loading and fallback behave differently from a Latin font. Treating them like “just another font” is exactly where the surprises come from.

This guide walks through what makes CJK fonts different from Latin fonts → how to use them in Figma → the Han unification trap → fallback and tofu (□) → performance → what to watch for when migrating from XD, in the order you actually hit them. Drawing on work verifying CJK text (Japanese, Chinese, Korean) conversion accuracy while building Pixel Fine Converter, it also folds in the practical points that matter at migration time. For a deep, Japanese-specific walkthrough (routes for adding fonts, symptom-by-symptom troubleshooting, XD migration notes), see the companion guide linked below.

What you’ll get from this article

• Why CJK fonts are fundamentally different from Latin fonts (glyph count, shared code points, file weight)
• The Han unification trap — “the same character renders differently per language” — and how to fix it
• How to choose the right Noto Sans CJK subfamily (SC / TC / JP / KR)
• The three causes of tofu boxes (□) and how to tell them apart
• Font and baseline pitfalls when migrating CJK designs from Adobe XD

🌏 What makes CJK fonts different from Latin fonts

A typical Latin font needs a few hundred glyphs to cover the alphabet, digits, punctuation, and accented characters. A CJK font is a different scale of object:

• Glyph count. A font that fully covers Chinese, Japanese, and Korean carries on the order of tens of thousands of glyphs. Google and Adobe’s pan-CJK family (Noto Sans CJK, known on Adobe’s side as Source Han Sans) is built to cover all three languages in one super-family.
• Shared code points. Through a Unicode design decision called Han unification, many Han characters used across Chinese, Japanese, and Korean were assigned a single code point — even when the regionally preferred shape differs. The font, not the character, decides which shape you see.
• Weight and file size. Because each weight has to draw thousands of characters, a single CJK weight is often several megabytes. That changes how fonts load and how fallback shows up while a font is still resolving.
• Layout expectations. CJK text has its own conventions — full-width punctuation, line-breaking rules, and (in print/editorial contexts) vertical writing. Not all of these are supported the same way in every tool, Figma included.

📥 Using CJK fonts in Figma

The three routes are the same as any font in Figma, but the choices within each route matter more for CJK.

Route 1 — Google Fonts (no setup). Figma ships Google Fonts, and the Noto CJK family is the most reliable cross-language starting point. The important detail is that each language has its own named font:

• Noto Sans SC / Noto Serif SC — Simplified Chinese
• Noto Sans TC (and HK) — Traditional Chinese (Hong Kong variant for HK)
• Noto Sans JP — Japanese
• Noto Sans KR — Korean

These are separate font families on purpose — choosing the right one is how you get the right regional glyph shapes (more on that in the next section).

Route 2 — Local fonts. Fonts installed on your machine (system CJK fonts, foundry fonts, licensed families) appear in Figma’s desktop app directly, and in the browser version once the local font support is enabled. This is how you reach fonts like Hiragino (macOS Japanese), PingFang (macOS Chinese), Apple SD Gothic Neo (macOS Korean), or Microsoft’s Yu Gothic / Microsoft YaHei / Malgun Gothic on Windows.

Route 3 — Adobe Fonts. If you have an active Adobe plan, activated Adobe Fonts (including Source Han Sans / Noto-equivalents and many commercial CJK families) become available to Figma once the local font path is set up.

⚠️ The Han unification trap — same code point, different glyph

This is the single most common CJK-specific bug in a Figma file, and it has nothing to do with anything being “broken.”

Because of Han unification, characters like 直, 骨, 雪, 麻, 茶, and many others occupy one Unicode code point but have different preferred shapes in Chinese, Japanese, and Korean. The stroke shapes, component placement, and proportions diverge. A native reader notices immediately; a non-CJK reader often cannot see the difference at all — which is exactly why it slips through review.

Figma renders each text run with one font, and the font carries one regional set of shapes. There is no per-character language tag the way CSS has a lang attribute. So:

• If you type Japanese text but the run is set to Noto Sans SC (Simplified Chinese), some characters will render with their Chinese shapes.
• If you paste Korean Hanja into a run set to a Japanese font, you may get Japanese shapes.

The fix is the font choice, not the text. Set Japanese runs to Noto Sans JP, Simplified Chinese to SC, Traditional Chinese to TC, Korean to KR. When a design mixes languages (a multi-locale UI kit, for example), keep each language on its own correctly-named font rather than relying on one “CJK” font to cover everything.

🔲 Font fallback and tofu (□) — when glyphs go missing

When a font has no glyph for a character, you get a missing-glyph box — often called tofu (□), the shape that gave Noto its name (“no more tofu”). With CJK this shows up in a few recognizable situations:

• The font genuinely lacks the character. A Latin-only or partial font has no CJK glyphs, so every CJK character becomes tofu.
• Rare or variant characters. Personal-name kanji, rare hanzi, or older variant forms may be missing even from large fonts.
• The font is still loading. Because CJK weights are large, you may briefly see fallback or boxes before the font resolves — especially in the browser version on a slow connection.

What to check, in order: confirm the layer’s font actually supports the language; if it’s a rare character, switch to a fuller family (Noto CJK is a safe bet for coverage); and if boxes appear only briefly, it’s a loading artifact, not a missing glyph. If a specific character is consistently tofu in every CJK font you try, it may be outside the font’s coverage — a more comprehensive or more specialized family is the only fix.

🖥️ Browser version vs desktop version for CJK

The browser-vs-desktop distinction matters more for CJK because the fonts are heavier and more often locally licensed:

• Desktop app. Reads the CJK fonts installed on your OS directly. Hiragino, PingFang, Yu Gothic, Microsoft YaHei, Malgun Gothic and similar system fonts are available without extra steps.
• Browser version. Google Fonts (including the Noto CJK families) work out of the box. To use local CJK fonts in the browser, the local font support has to be enabled — otherwise those families simply won’t appear, and the layer falls back.

For the full setup steps and the symptom-by-symptom fixes (which apply to CJK as well as Japanese), see the fonts not showing guide.

⚡ Performance — CJK fonts are heavy

A single CJK weight can be several megabytes because it draws thousands of characters. In practice that means:

• First load is slower. The first time a CJK font is used in a file, there can be a noticeable delay before text settles, particularly in the browser version.
• Many weights add up. Loading regular, medium, and bold of a CJK family is meaningfully more data than the equivalent Latin weights. Stick to the weights you actually use.
• Subsetting is a delivery concern, not a Figma editing one. When you hear about “subsetting” CJK fonts (shipping only the glyphs a page needs), that’s about serving fonts on a live website. Inside Figma you work with the full family; the takeaway for design work is simply to be deliberate about how many CJK families and weights a file depends on.

The design-time lesson is restraint: a file that pulls in four Noto subfamilies × four weights is carrying a lot of font data. Decide the families you need per language and keep the weight set tight.

🔄 Migrating CJK designs from Adobe XD

If your CJK design was created in Adobe XD, the migration requires one more step on top of everything above: the font the layer references has to resolve to the right CJK family on the Figma side, with the right regional shapes and metrics.

Two things tend to go wrong in a naive migration:

• Font substitution loses the language. If the original XD font isn’t present in Figma, a generic substitution can drop you onto the wrong regional shapes — re-introducing the Han unification problem from a different direction.
• Baseline and metrics shift. CJK glyphs sit on different vertical metrics than Latin glyphs. A converter that doesn’t account for this can leave CJK text visibly misaligned after import.

This is the part of CJK work that a purpose-built converter handles for you. Pixel Fine Converter reads the XD file directly and is designed with migration accuracy as a core priority — including dedicated handling for CJK text (Japanese, Chinese, Korean) so baselines and glyphs land correctly instead of needing manual cleanup. For how the rendering accuracy is verified, the Japanese text fidelity guide goes into the specifics; for the overall move, see the XD → Figma migration guide.

🎨 Recommended CJK fonts by language

A practical default per language, balancing coverage, availability, and how reliably everyone on a team can see the same thing:

For shared, multi-locale files, the Noto column is the safer choice — it requires no installation and renders identically for everyone. Reach for the local/system column when a platform-native look is the explicit goal.

💬 FAQ

Q: Can one font cover Chinese, Japanese, and Korean at once? A pan-CJK family like Noto Sans CJK / Source Han Sans technically contains glyphs for all three. But for shared characters it renders one region’s shapes by default, so for correct per-language shapes you should still assign the language-specific subfamily (SC / TC / JP / KR) to each text run.

Q: My characters look “slightly wrong” but not broken. What’s happening? That’s almost always the Han unification issue — the text is set to a font for the wrong language, so shared characters show another region’s shapes. Switch the layer to the correct regional font (e.g., Noto Sans JP for Japanese).

Q: Why do I see empty boxes (□)? Either the font has no glyph for those characters (use a fuller CJK family like Noto), the character is rare/variant, or the (large) font is still loading. Confirm the font supports the language first.

Q: Does Figma support vertical CJK text (tategaki)? Vertical writing is a common CJK editorial need, but it isn’t a native Figma text feature as of this writing. Teams typically work around it; if true vertical text is essential, plan for that limitation rather than expecting a toggle.

Q: My CJK font from XD didn’t survive the move to Figma. Why? If the font isn’t available in Figma it gets replaced, which can substitute the wrong regional shapes and shift metrics. A migration-focused converter with CJK handling avoids most of this — see the section above.

🎯 Recap

CJK fonts are steady to work with once you know which points to watch. Here are the five takeaways from this guide:

Get the language-to-font mapping right and most “mysterious” CJK rendering issues disappear. If your CJK design was created in Adobe XD, the migration is where the font and baseline accuracy is easiest to lose — and using a purpose-built converter is what saves the most cleanup.

Related pages

• Using Japanese fonts in Figma — Japanese-specific depth: adding fonts, troubleshooting, font choices
• Why Figma fonts aren’t showing — Browser/desktop setup and symptom-by-symptom fixes
• How accurately can Japanese text move from Adobe XD to Figma? — A deep dive into XD → Figma rendering accuracy
• XD → Figma migration: a practical guide — Concrete steps and preparation after deciding to migrate
• Features: Japanese fonts — Per-font correction details in Pixel Fine Converter