Japanese UI Character Limits:
A Practical Guide for Product Teams

▶ 60-Second Slide Summary Prefer the 10-slide version of this article? Tap to read in 60 seconds. View slides →

TL;DR

Japanese UI text does not expand uniformly — it expands in ways your design system probably does not account for. Kanji glyphs are visually heavier than Latin characters, button labels run shorter in characters but wider in pixels, and form labels run longer. Product teams that ship Japanese without per-component character limits end up with truncated CTAs, broken nav bars, and silent abandonment of conversion-critical screens.

Key Takeaways

• Expansion is not uniform — Japanese averages 0.5–0.7× English character count but 1.0–1.3× pixel width because of fullwidth glyphs.
• Buttons are the worst offenders — fixed-width CTAs designed for "Get started" rarely fit "無料で始める" without wrapping or truncation.
• Form labels run longer — Japanese form labels often need 1.5× the horizontal space of English equivalents.
• Specify per-component limits — give translators max character counts AND max pixel widths in the localization brief, not just one or the other.
• QA in the actual UI — text that fits in a spreadsheet often breaks in production. Always review localized strings in context, not just as a string list.

Why Japanese UI Strings Break Western-Built Layouts

Most SaaS products are designed in English first. That design carries implicit assumptions about character width, line height, word boundaries, and how text wraps when constrained. Japanese breaks almost all of those assumptions in ways that are invisible to designers who do not read the language.

Japanese mixes three writing systems — kanji, hiragana, and katakana — and each character occupies a fullwidth cell roughly the width of two Latin characters. A six-character English word like "Login" becomes the three-character "ログイン," which sounds shorter but consumes nearly the same horizontal space. Character count and pixel width tell two different stories. Product teams that only track character count are systematically underestimating Japanese UI width.

This is not a minor visual issue. Truncated CTAs lose clicks. Overflowing nav items push primary actions off-screen on mobile. Form labels that wrap to two lines change the perceived complexity of the signup. And most of these problems enter silently during localization — not caught in design review, not caught in QA, discovered by a Japanese user who just gives up.

The Real Numbers: How Japanese Text Expansion Actually Works

The single most common source of confusion is the expansion ratio. Internal documentation at most SaaS companies cites a single number — usually something like "Japanese expands 1.2× English" — that falls apart the moment it meets real product strings.

The expansion ratio depends on three variables: source content type, target string style, and what you are measuring (characters versus pixels). Here is what the numbers actually look like across common SaaS string categories:

String type	EN → JA character ratio	EN → JA pixel width ratio	Notes
Button labels (CTA)	0.4–0.7×	1.0–1.4×	Fewer characters, wider per character. Most common breakage point.
Nav menu items	0.5–0.8×	1.0–1.3×	Wide kanji compress meaning but consume horizontal space.
Form labels	0.6–1.0×	1.1–1.5×	Polite forms (お名前, ご住所) add honorific prefixes that increase width.
Error messages	0.8–1.3×	1.0–1.4×	Required polite verb endings add length to short alerts.
Body paragraph	0.5–0.8×	0.9–1.1×	Reads denser per line; rarely a layout problem.
Help center articles	0.5–0.7×	0.9–1.0×	Typically not constrained by layout.

The pattern is consistent: as strings get shorter, the pixel-width expansion gets worse. Single-word CTAs are the riskiest category. Long-form body content rarely breaks layouts. This is the opposite of what most engineering teams assume.

Where Japanese Character Limits Hit Hardest in SaaS UI

Five UI components account for most Japanese localization breakage in B2B SaaS products. I've reviewed dozens of these, and the same components fail every time. Catching them in design before localization begins eliminates most production issues.

1. Primary CTAs and signup buttons

Fixed-width primary buttons are designed for English action verbs of 8–14 characters. Japanese equivalents either fit awkwardly or do not fit at all. The fallback — shrinking the font size or wrapping to two lines — looks unprofessional and reduces click rate.

2. Top navigation

Navigation bars with 5–7 items at fixed spacing tend to overflow on Japanese mobile screens. Items like "Pricing" (7 chars) become "料金プラン" (5 chars but visually wider), and "Get a demo" becomes a multi-word phrase that does not compress easily.

3. Form labels and field placeholders

Japanese form labels use honorific prefixes (お, ご) for politeness in B2B contexts. "Name" becomes "お名前," which is wider than the English equivalent in most layouts. Two-column form layouts designed for short English labels often need to switch to stacked layouts in Japanese.

4. Empty states and onboarding tooltips

Short empty-state messages ("No projects yet") tend to expand in Japanese ("プロジェクトがまだありません"). Tooltip arrows that point to specific UI elements assume a certain bubble width. Both break when Japanese expands beyond the design budget.

5. Tables and dashboard summary cards

Column headers, summary card titles, and dashboard widget labels are nearly always tighter in Japanese pixel-width than in English. Numeric formatting also differs — Japanese often groups numbers in 万 (10,000) units, which affects column width allocation.

Hard Limits, Soft Limits, and What to Specify in Localization Briefs

Most localization briefs specify a single character limit per string — and that is the wrong abstraction. Professional Japanese localization briefs distinguish between three constraint types. Getting these right in your TMS or localization platform eliminates most rework.

• Hard character limit: The absolute maximum number of characters that will fit. Translators must not exceed this. Useful for fields with database column constraints (display_name VARCHAR(40), for example).
• Soft character limit (preferred): The recommended target the translator should aim for. Useful when you want translators to produce concise output but have some flexibility.
• Maximum pixel width: The actual rendering constraint. The single most useful number for UI strings, because it captures the kanji-width problem that character counts miss.

Most major localization platforms (Phrase, Lokalise, Crowdin, Transifex) support per-string character limits as metadata. Few teams use pixel-width metadata even where it is supported, because it requires the design system to expose those values in the first place. Adding this metadata to your design tokens is a one-time investment that pays back on every future localization.

Common Anti-Patterns Engineering Teams Apply

Several common engineering responses to Japanese UI breakage make the problem worse over time. Here is what usually happens — and why it backfires.

Reducing font size for Japanese only

Tempting because it makes everything fit, but Japanese kanji become harder to read at small sizes — the visual complexity that makes kanji wider also makes them dependent on a minimum legible size. Anything below 12px Noto Sans JP starts to lose stroke detail. This change usually shows up in user research as "the Japanese version feels harder to use" without users articulating why.

Auto-truncating with ellipsis

CSS truncation (text-overflow: ellipsis) is a quick fix but signals an incomplete product. Japanese users see truncation as a sign that the Japan version is an afterthought. Worse, the truncated text often hides the most important word — Japanese sentence structure puts the verb at the end, which is also the part most likely to be truncated.

Switching to compressed fonts for the Japanese build

Condensed Japanese fonts exist but are designed for print at large sizes. They are not legible at typical UI sizes and signal poor design judgment to Japanese readers. Reserve them for hero typography only, never for body text or interactive UI.

Letting translators handle it without design feedback

Translators can choose shorter wording when given the constraint, but cannot rewrite the source design. If your button width allows 6 fullwidth characters, the translator can hit that target. If you give them no constraint and provide only the source string, they will produce semantically correct Japanese that may not fit your UI.

The Pre-Localization Design Audit: 8 Checks Before Strings Go to QA

The most cost-effective Japanese UI work happens before localization begins, not after. Running this audit on your design system before your first Japanese release saves significant downstream rework.

Working with Localization QA Effectively

The most important relationship in this workflow is between the product team and the Japanese QA reviewer. Translators who never see the rendered UI cannot help with layout issues. QA reviewers who only see strings cannot catch contextual problems. The teams that ship the best Japanese UIs treat localization QA as a stage of design review — not a final translation check.

For SaaS teams shipping Japanese for the first time: engage native Japanese QA before, during, and after the first release — not just at the end. Pre-launch design audits catch structural issues that are expensive to fix later. Post-launch QA on the actual production UI catches contextual issues that string-list review always misses.

For teams already shipping in Japanese, the next-best decision is to add per-string maximum width metadata to your design tokens and localization platform, so future strings can be validated automatically against the constraints that actually matter.

Frequently Asked Questions