Japanese type has a different rendering personality than Latin type. Even with correct strings and correct register, an app whose Japanese typography is misconfigured looks foreign-made. This article covers what typography decisions affect that perception, and what to do about them on iOS and Android.
For broader localization context, see the complete guide to Japanese app localization.
Japanese Type: What's Different
Three structural differences from Latin type:
1. Each character is wider and taller. A Japanese character occupies roughly the space of a square em — what typographers call "full-width." Latin letters are ~half that width. This affects line length, line height, and visual density.
2. There's no word spacing. Japanese text has no spaces between words. Line-break decisions happen between any two characters (with conventions on which boundaries are preferred).
3. Three scripts coexist with different visual weights. Hiragana is curvy and light. Katakana is angular and slightly heavier. Kanji is dense, complex, and dark. A line of mixed Japanese has a "rhythm" of light/heavy regions that Latin text doesn't have.
These differences mean settings that are fine for English text — line height, letter spacing, font weight — produce visibly off Japanese type if applied unchanged.
System Fonts on iOS
iOS system Japanese fonts are excellent. The defaults work for most apps.
- iOS 13+ default: "Hiragino Sans" / "ヒラギノ角ゴシック" — clean modern sans-serif.
- Older iOS: "Hiragino Kaku Gothic ProN."
- System UI font: SF Pro automatically falls back to Hiragino for Japanese characters.
If you use the system font (-apple-system, SF Pro, San Francisco in CSS, or .appearance() defaults in SwiftUI/UIKit), Japanese characters render with Hiragino Sans automatically. This is the right default. Don't override it without reason.
When you'd override
- You ship a custom brand font for Latin text and need a Japanese counterpart that matches in weight and style.
- You need a serif (Mincho) family for a reading app.
- You need a particular weight not available in the default font.
When you do override, common iOS-bundled options:
- HiraginoSans-W3 / W6 — light and bold sans-serif.
- HiraMinProN-W3 / W6 — light and bold mincho (serif).
- YuGothic-Medium / Bold — alternate sans-serif, slightly more contemporary feel.
- YuMincho-Medium / Demibold — alternate mincho.
Avoid declaring fonts that don't exist on iOS. The fallback chain produces inconsistent rendering across iOS versions.
System Fonts on Android
Android's Japanese rendering is more variable across devices and OS versions. The system default is Noto Sans CJK JP on most modern devices, but older devices may use vendor fonts (Samsung's own, etc.) that look slightly different.
For consistency:
- Bundle Noto Sans JP with your app and reference it explicitly.
- Provide weights (400/500/700) explicitly; Noto's weight axis differs from Latin Noto.
- Test on at least one Samsung device, one Pixel, and one mid-range Asian-market Android — vendor font substitution can produce subtle visual differences.
Noto Sans JP weight names
| Weight | Name | Use |
|---|---|---|
| 100 | Thin | Display only |
| 300 | Light | Body in airy designs |
| 400 | Regular | Default body |
| 500 | Medium | Slight emphasis, headings |
| 700 | Bold | Strong emphasis |
| 900 | Black | Display only |
Most app UIs need only Regular and Bold (or Medium if you use medium for headings).
Custom Fonts: The Fallback Problem
If you ship a custom Latin font for branding (Avenir, Inter, Manrope, your own), Japanese characters in that font are almost certainly missing. Without intervention, the OS falls back to its default Japanese font.
This produces an aesthetic mismatch: your custom Latin font has a particular weight/style, the system Japanese font is something else, and mixed Latin-Japanese strings look like two unrelated typefaces.
Solution patterns
1. Pair your Latin font with a Japanese-language font that visually matches.
If your brand font is geometric sans-serif, pair it with a geometric Japanese font. If it's humanist, pair it with a humanist Japanese font. Approximate pairings:
- Inter / SF Pro → Hiragino Sans / Noto Sans JP
- Helvetica / Arial → Hiragino Kaku Gothic / Yu Gothic
- Avenir / Futura → Tsukushi A Round Gothic / FOT-Skip Std
- Garamond / serif brand fonts → Hiragino Mincho / Yu Mincho
2. Use a multilingual typeface that covers both.
Some commercial fonts have matched Latin and Japanese cuts: TBUDGothic, SST Japanese, Noto Sans (the Latin is designed alongside the JP). This avoids the pairing problem.
3. Set explicit font fallback chains.
iOS:
// In SwiftUI or UIKit, the system handles fallback for unicode ranges,
// but if you override the font, also specify a JP fallback explicitly.
let font = UIFont(name: "Inter-Regular", size: 16)
// JP characters fall back to system; if that's wrong, use NSAttributedString
// with multiple font ranges.
Android:
<!-- res/font/inter_with_jp.xml -->
<font-family>
<font android:font="@font/inter_regular" />
<font android:font="@font/noto_sans_jp_regular"
android:fontVariationSettings="..." />
</font-family>
In practice, the cleanest solution is to ship a paired Japanese font and use it for any UI element that displays Japanese text, controlled by the user's locale.
Weight Calibration
Japanese type at the same nominal weight looks visually heavier than Latin type. A 16pt Latin font set in 400 weight looks fine. The same 16pt Japanese font in 400 weight may look slightly bold because of the kanji density.
Practical implications:
- Body text: Japanese often looks correct at one weight lighter than the Latin equivalent. If you use Regular for English body, try Regular or even Light for Japanese on the same screen.
- Headlines: Bold Japanese reads as very bold. Medium often works where Bold would in English.
- Captions: Japanese small text needs slightly more weight than Latin to remain legible. The rule reverses at small sizes.
This is a calibration problem you solve by reviewing the rendered UI on device, not by reading the spec.
Line Height (Leading)
Japanese characters have larger visual mass per line than Latin. They need more line height to breathe.
Recommended line-height multipliers (relative to font size):
| Use | Latin | Japanese |
|---|---|---|
| Body text | 1.4–1.5 | 1.6–1.8 |
| Compact UI text | 1.2–1.3 | 1.4–1.5 |
| Headlines | 1.1–1.2 | 1.2–1.3 |
If your design system was built for English and you keep the same line-height tokens, Japanese text will feel cramped. The fix is to define separate line-height tokens for Japanese-locale builds, or use the larger value for both.
Letter Spacing (Tracking)
Default tracking for Japanese is 0 — Japanese characters are designed to sit naturally with no spacing. Adding positive tracking spreads characters in a way that looks deliberately stylized (sometimes used in headlines for impact, never for body).
Latin tracking conventions don't transfer. If your design system has tracking: -0.02em for body Latin, do not apply it to Japanese.
Punctuation Spacing and Half-Width Marks
Japanese punctuation 「、」「。」 takes a full-width slot, with built-in visual breathing room. Some apps trim this with custom spacing, which makes Japanese punctuation look squished. Don't.
Mixed Japanese-Latin lines need spacing between scripts:
❌ AppleからメッセージA new feature is available ✅ Appleからメッセージ A new feature is available
A half-width space is conventional between katakana/Latin and adjacent Japanese script when the meaning would otherwise blur. iOS and Android typography engines do not insert this automatically.
Line Breaking
Japanese line-break rules govern where a line can break. Modern OS text engines mostly handle this correctly, but specific edge cases:
- Particle isolation: A particle like 「を」 should not appear alone at the start of a line. iOS handles this; some Android implementations don't.
- Punctuation orphans: A 「。」 should not start a line. This is universally enforced.
- Mid-word breaks: Loanwords (long katakana strings) can break mid-word in modern type engines, but it looks wrong. Custom layouts should avoid this.
If you implement custom text layout (a game, custom rendering, canvas-based UI), implement Japanese line-break rules explicitly. The standard reference is JLREQ (Japanese Layout Requirements), the W3C document.
Vertical Text
Japanese can be written top-to-bottom, right-to-left columns. Mobile apps almost never use vertical text. Exceptions:
- Reading apps for novels and manga.
- Calligraphy/cultural-heritage apps.
- Stylistic display elements (loading screens, splash screens).
Implementing vertical text in iOS/Android is non-trivial — you cannot flip a horizontal text view; you need vertical-text-capable rendering. CoreText supports this on iOS; Android requires custom drawing. We cover this in vertical text and layout considerations in Japanese apps.
A Quick Typography QA Pass
Before shipping Japanese type:
- Mixed Latin/Japanese strings use a font pairing that visually matches in weight and style.
- Line height is loosened for Japanese text relative to Latin.
- Letter spacing is 0 (or near-zero) for Japanese.
- No tracking-tightened body text.
- Punctuation is full-width, with native spacing preserved.
- No 「を/が/は」 orphans at the start of lines.
- No 「。/、」 orphans at the start of lines.
- At small sizes, Japanese remains readable (it likely needs more weight than Latin would).
- At display sizes, Japanese isn't over-bold (likely needs less weight).
- Test on Samsung, Pixel, and one mid-range Android in addition to iPhone.
Where to Go Next
- Hiragana, Katakana, or Kanji? Choosing the Right Script
- Mobile UI Conventions Japanese Users Expect
- Handling Japanese Text Expansion in Mobile UI
- Vertical Text and Layout Considerations in Japanese Apps
We help teams calibrate Japanese typography on shipping apps — pairing fonts, tuning line heights, fixing weight mismatches. Contact us for a typography audit.