Japan App Store Screenshots: Keigo + Hiragino Rules [2026]

Japan is the third-largest App Store market by consumer spend, behind only China and the United States, and the country with the highest per-capita mobile app spending in the world [1]. The screenshot layer is the part most indie teams get wrong. Japanese readers tolerate two to three callouts per frame where US readers expect one [2]. The wrong politeness register (casual where polite is expected, or super-formal where polite-friendly is expected) signals "non-native team" inside a single caption. The iOS system font for Japanese is Hiragino Sans [3], and an English designer font that lacks CJK weights will silently fall back to it mid-caption, producing a visible weight mismatch. Plan for these three layers (density, register, font fallback) before translating a single word.

This is the Japan-specific execution deep-dive that sits under the 7-market screenshot localization priority guide. The pillar covers when and why to localize Japan; this post covers how the screenshot composition, the caption tone, and the typography all need to shift, beyond running the source captions through a translator.

TL;DR:

• Japanese app screenshots can stack 2 to 3 callouts per frame because Japanese mobile UI tolerates higher information density than Western minimalism [2]. The layouts that absorb this best: feature-callout, stats-hero, social-proof. The layouts that break: device-hero with a single overlaid caption, lifestyle-hero with a single big visual hook.
• The polite-friendly register (teineigo, ending in desu and masu) is the safe default for productivity, fintech, and health categories [4]. Super-formal keigo reads as cold; casual futsūtai reads as sloppy. Casual mobile games can use futsūtai; matching app-character tone to category convention matters more than length.
• Japanese expands minus 10 to 0% versus English on average [4], so the layout doesn't break the way German does. The danger is tone, not space.
• iOS ships Hiragino Sans as the Japanese system font [3]. A custom English screenshot font without CJK weights will fall back to Hiragino at runtime for Japanese characters, producing a visible mixed-font effect. Prefer system fonts for the Japanese caption layer and reserve a custom font for the English brand mark only.
• Japanese apps mix half-width (半角) and full-width (全角) digits depending on context [5]. Modern app numerals, prices, and stats default to half-width. Postal addresses and formal documents use full-width. Don't auto-convert one to the other.
• Currency renders as 1,247円 (yen character after) or ¥1,247 (symbol before); dates as YYYY/MM/DD with 年月日 markers. Stat-hero and feature-callout layouts surface these the most.

Table of Contents

• Why does Japan rank #3 but get localized last?
• What does Japanese information density look like layout by layout?
• When does anime and character art convert in Japan?
• How do you pick the right keigo register for your app category?
• What CJK font and typography rules apply to Japanese screenshots?
• How should currency, dates, and digits render in Japanese stat panels?
• When should you redesign versus accept the Japanese render?
• Takeaways

Why does Japan rank #3 but get localized last?

Japan is the third-largest App Store market by consumer spend globally [1]. Homegrown Japanese publishers hold around one-third of download share but capture more than half of total in-app purchase revenue, which tells you everything about how Japanese users behave: they download less, they pay more, and they prefer apps that feel native [1]. Gaming, lifestyle, entertainment, and subscription verticals concentrate the revenue. For those categories, Japan often outranks Germany and the UK on per-app revenue.

Indie teams localize Japan late for two reasons, both wrong. First, the perceived translation cost feels higher because of the script change. In practice the per-string translation cost is similar to European languages; the cultural-adaptation cost is what's different. Second, teams default to running the existing English screenshot set through a translator and shipping the result. That produces a listing that reads as machine-translated to Japanese users in a way a literal text comparison won't surface, because the cultural mistake is in tone, density, and visual convention, not in word choice.

The right ROI math for Japan: if your category is gaming, anime-adjacent lifestyle, subscription productivity, fintech, or anything with monthly recurring revenue, Japan is usually the second market to localize after US English. The per-user revenue justifies the cultural-adaptation work in a way Korean or Brazilian Portuguese (both also high-ARPU) don't always match.

What does Japanese information density look like layout by layout?

The "Japanese tolerates higher information density" rule [2] is true but not actionable until you map it onto screenshot layouts. Western minimalism shows one feature, one hook, one number per frame [2]. Japanese app screenshots in the same category can stack two or three callouts, plus the device, plus a small trust-signal cluster, on the same frame without reading as cluttered to a Japanese user.

The implication: layouts built around a single hero element absorb less translation cost, but they also leave Japanese conversion on the table. Layouts built around stacked callouts read as restrained-minimalist in Japan but as "too much" in the US. Picking the right layout per market matters more than picking the right caption.

The practical rule for a JP-targeted set: use feature-callout, stats-hero, or social-proof for at least three of the first five frames. The English original might use device-hero for frame 1 and lifestyle-hero for frame 3; for the Japanese set, swap those to feature-callout and stats-hero respectively, and the conversion math usually clears.

The feature-callout layout breakdown covers the icon + label + sub-text composition, and the stats-hero layout breakdown covers how multiple numbers compose without breaking visual hierarchy.

When does anime and character art convert in Japan?

Anime and character art are stereotyped as "the Japanese style," but the conversion data is more specific. Manga and anime aesthetics work in gaming, anime-adjacent lifestyle apps, education (especially language learning), and entertainment apps where the visual world is itself part of the product. They actively hurt trust in fintech, health, productivity, and any data-handling category, because they read as "fun but not serious" in a market where serious is the table-stakes signal for financial trust.

The rule isn't "use anime in Japan, don't use it outside Japan." It's "match the visual style to the category convention as Japanese readers see it, not as Western readers see it." A finance app in Japan that uses anime mascots reads exactly as a US finance app that uses cartoon graphics: cute, but not where I want to keep my money. A learning app in Japan without character illustration reads as cold and clinical, even if the same austere style would be brand-defining for an English-market competitor.

Photographic realism with Western models is the silent killer. A fitness app screenshot showing only Western faces, a meditation app showing only Western posture and clothing, a dating app showing only Western relationships, all read as "this product is not for me" to Japanese users. The fix is straightforward: photograph or commission visuals with models who represent the target demographic, and use the fitness frame 1 hook patterns framework adapted with local-market models in the lifestyle frames. The finance frame 1 trust-first hook post covers the parallel rule for fintech where the visual signal has to read as "regulated and serious" first.

How do you pick the right keigo register for your app category?

Japanese has formal and informal registers, and matching the right level to your app category signals "designed by a native team" or "translated by someone outside the market" inside a single caption [4]. The three registers that matter for App Store copy:

• Teineigo (polite): Standard polite form, sentences ending in desu and masu [4]. This is the safe default for almost every app category. Reads as professional but approachable.
• Futsūtai (casual): Plain form, used between friends and family [4]. Appropriate for casual mobile games, social apps with a youthful audience, and entertainment apps deliberately styled as conversational.
• Sonkeigo and kenjōgo (super-formal honorific and humble forms): Used for high-deference business contexts. Almost never appropriate for App Store copy. Reads as cold and distant.

The category-level defaults that work:

• Fintech, banking, investing: Teineigo. The market expects polite-professional, not super-formal. Japanese banking apps that use sonkeigo read as old-fashioned and bureaucratic. The polite-friendly register signals "modern Japanese fintech," which is the active brand direction in the market.
• Health and meditation: Teineigo, with softer phrasings on calls to action. Avoid the imperative form even in polite register; "Start your session" reads better as "Let's start your session" tone-wise.
• Productivity and B2B: Teineigo. Same as fintech.
• Casual gaming: Futsūtai is acceptable and often preferred. Match the in-game character voice if the app has one.
• Education and language learning: Teineigo for adult learners, futsūtai with care for kids' apps.
• Dating and lifestyle: Teineigo, leaning toward warmer phrasing. The "polite but friendly middle level" most modern Japanese consumer brands use.

The cost of getting this wrong is invisible to anyone outside the market. An English caption like "Try it free" can translate three different ways in Japanese, and the three reads as casual, polite, or super-formal respectively. Translators paid per word default to teineigo, which is usually right, but a native review pass on the final copy is the difference between "this brand understands Japan" and "this brand ran the English through a translator."

What CJK font and typography rules apply to Japanese screenshots?

Apple ships Hiragino Sans as the Japanese system font on iOS [3]. This is what Japanese users see in Notes, Mail, Messages, and most native apps. A screenshot rendered with Hiragino Sans for the Japanese caption reads as native iOS; one rendered in a custom designer font reads as marketing-not-product.

The technical trap: many English designer fonts ship glyphs for Latin characters only. When the rendering engine encounters Japanese characters, it falls back to the nearest available CJK font, which on iOS is Hiragino [3]. The user sees a caption where the English brand mark uses your designer font and the Japanese caption uses Hiragino, with a visible weight mismatch between the two. The fix is one of three options:

1. Use Hiragino Sans for the Japanese caption layer. Keep the English designer font for the brand mark only. The two-font composition reads cleanly as long as the weight pairing is intentional (Hiragino Sans W3 pairs cleanly with most modern English geometric sans-serifs).
2. Use a CJK-compatible English font that ships Japanese glyphs. Noto Sans, Source Han Sans, and a small set of commercial fonts (Helvetica Now, Roboto with the Noto fallback) cover this. Cost: the visual personality compromises toward neutral.
3. Set the whole composition in Hiragino. For brands without a strong typography identity, this is the lowest-effort path and produces the most native-feeling result.

Avoid setting the whole composition in a custom English font and hoping. The fallback will happen, and the visible split between two font families inside one caption is the single most-spotted "this isn't a Japanese product" signal.

One additional rule: ambiguous CJK characters can fall back to Simplified Chinese glyphs in some font stacks, which displays as visibly wrong to Japanese readers (the strokes draw differently between zh-CN and ja-JP for the same Unicode codepoint). When specifying fonts in a screenshot rendering pipeline, declare the locale explicitly so the renderer picks the Japanese glyph set rather than defaulting to Chinese.

How should currency, dates, and digits render in Japanese stat panels?

Stats-hero and feature-callout layouts surface numbers more than any other layout, and the formatting rules are different for Japanese than for English. The defaults:

• Currency: Either 1,247円 (with the yen character 円 after the number) or ¥1,247 (with the yen symbol before). Modern Japanese apps lean toward the post-positioned 円 in formal financial contexts and the prefixed ¥ in casual contexts. App Store screenshots can use either; consistency within the set matters more than which one you pick.
• Decimal and thousand separators: Period for decimal, comma for thousands. Same as US English. Japanese doesn't flip this the way German does.
• Date format: YYYY/MM/DD numerical, or YYYY年MM月DD日 with the era markers [5]. For a stat panel showing "Members since 2024" the YYYY年 format reads more natively; for a calendar UI the YYYY/MM/DD format reads as standard.
• Half-width versus full-width digits: Modern Japanese apps default to half-width (1,247) for numerical values [5]. Full-width digits (１,２４７) are correct in postal addresses, formal documents, and some legacy contexts but read as old-fashioned in modern app UI [5]. Don't auto-convert half-width to full-width when localizing; that's the most common bot-translation mistake.

The practical rule for stat panels: keep the numerical value in half-width digits matching the English source, and translate only the label (the caption "users" becomes ユーザー, the caption "downloads" becomes ダウンロード). A stat-hero frame that shows "1.2M users" in English becomes "1.2Mユーザー" or "120万ユーザー" in Japanese; either reads natively. What doesn't read natively is "１.２Mユーザー" with full-width digits.

When should you redesign versus accept the Japanese render?

The redesign decision tree for a Japanese localization pass, applied per frame:

• The caption fits within the original layout with no overflow and no awkward wrap. Accept the render. Japanese expansion is near-zero on average [4], so this is the common case.
• The caption fits but the density feels too low for the JP market. Add a sub-caption or a 2-bullet annotation. Don't redesign the whole frame.
• The visual hook is photographic with Western models. Redesign the visual layer. Replace with locally-appropriate models or switch to a non-photographic style (illustration, abstract, product hero).
• The caption tone reads wrong for the category. Edit the translation, not the design. This is a copy fix, not a layout fix.
• The font fallback is producing a mixed-font caption. Switch to Hiragino Sans for the Japanese layer. This is a render-pipeline fix.
• The numerical format is wrong (full-width digits, wrong currency position). Edit the data layer, not the design. Most rendering pipelines surface this as a templating option rather than a layout decision.

The decision tree concentrates redesign cost on the visual layer (models, illustration style) and routes everything else to copy or render-pipeline fixes. That's the inverse of the German case, where the design layer takes the brunt of expansion. Japan's challenge is taste, not space.

For teams running localization manually, this means budgeting native review of the copy and a designer pass on visuals with local models, not budgeting a parallel design pass per language. The human cost concentrates on tone review and visual style choices; the font-stack and digit-width pieces can be automated.

Takeaways

Japanese App Store screenshots fail in the cultural layer, not the space layer. Density tolerance is higher than US norms, so the layouts that win in the US (single hook, lots of whitespace) leave conversion on the table; switch to feature-callout, stats-hero, or social-proof for at least three of the first five frames. The polite-friendly teineigo register is the safe default for almost every category; super-formal sonkeigo reads as cold and casual futsūtai reads as sloppy in serious categories. Hiragino Sans is the iOS system font for Japanese [3]; using a custom English font without CJK weights produces a visible mixed-font effect that's the single most-spotted non-native signal.

The visual layer carries more weight than the caption layer for Japan. Photographic realism with Western models hurts trust in lifestyle, dating, and fitness. Anime and character art convert in gaming, education, and entertainment but kill trust in fintech, health, and productivity. The "match the category convention as Japanese readers see it" rule beats "use anime because Japan" by a wide margin.

If you're localizing manually (Photoshop or Figma per language, hand-pasted captions, manual font swaps), the per-market cost for Japan stays high because every frame needs a tone check plus a font check plus a digit check. The 7-market screenshot localization priority guide covers when Japan belongs at position 2 (subscription, gaming, fintech) versus position 5 (broad consumer with limited APAC exposure). The cultural adaptation pillar covers the cross-cutting design rules (RTL, color meaning, imagery) that apply across the broader East Asian regional cluster Japan sits inside.