App Store Character Limits: 19 of 41 Locales Overflow

TL;DR: The App Store name and subtitle fields are capped at 30 characters, and that cap is fixed per locale, not per app. Translate a 26-character English name into German and it projects to 35 characters, over the limit, because German runs about 35% longer than English. That is the single worst case among the 41 App Store locales in our localization-readiness dataset. 19 of those 41 locales land in a high overflow-risk bucket once you translate into them. A 26-character English name fits without edits in only 10 of the 41 locales at the 30-character cap. This post breaks down which locales expand, which contract, why right-to-left languages break the "just count characters" heuristic completely, and how to write copy that survives the worst locale instead of just the English source.

The 30-character cap is per-locale, not per-app

App Store Connect enforces the same 30-character limit on your app name and subtitle in every localization you submit, English included. Developers usually design against the English string, get it to fit with room to spare, and assume the translated versions will follow. They do not. A word that takes 26 characters in English can take 35 in German, because German compounds words instead of using separate short ones (think Kundenbetreuung instead of "customer support"). Submit that translation and App Store Connect rejects it for the German locale specifically, while every other locale sails through. The fix is not "write a shorter name." It is knowing, before you commission the translation, which locales will blow the budget so you can design the source string with that ceiling in mind.

We built the localization-readiness dataset behind this post because we kept seeing the same support ticket: a founder ships a clean English listing, sends it to a translation vendor, and gets four or five rejection emails back from App Store Connect a week later, one per overflowing locale. Each rejection costs a resubmission cycle, and App Review turnaround runs one to two days on a good week. Catching the overflow before the translation is commissioned turns a week of back-and-forth into a five-minute check against 41 numbers.

The same cap applies to more than the app name. Subtitles share the 30-character limit, and promotional text runs to 170 characters. Screenshot captions are not governed by App Store Connect at all, but they inherit the same problem: a caption designed to fit a fixed-width overlay in English will run past that overlay in German or Finnish unless you designed the overlay with the worst-case locale's length in mind from the start.

Which locales run longest

Expansion is not evenly distributed. German is the extreme case in our dataset at +35%. A tight cluster of Northern and Central European languages sits at +25% to +30%, and that cluster is where most indie teams get caught off guard because they only budget for German and assume everything else is safer.

Of the 41 locales we track, 19 fall into the high overflow-risk bucket after translation. That is close to half your localization footprint, and it includes most of Western and Eastern Europe once you count Spanish, Swedish, Czech, Croatian, Slovak, Slovenian, and Serbian, all sitting at +25%. Estonian and Lithuanian join that same +25% band. Persian, at +25% and right-to-left, and Urdu, at +20% and also right-to-left, stack two risk factors on top of each other: their translated strings run long, and their layout mirrors, so a fix for one does not touch the other.

A useful way to read this table is by market, not just by language. If your app targets the DACH region, Poland, or Brazil, three of your highest-volume markets by App Store revenue, you are also targeting three of the four longest-running locales in the entire dataset. There is no way to treat those markets as an afterthought once translation starts; the character budget has to be part of the initial design brief, not a fix applied after the first rejection.

Which locales get shorter, and why that is not automatically safe

Go the other direction and the character-per-word math flips. Chinese runs about 50% shorter than English by character count, Japanese about 45% shorter, Korean about 40% shorter. On paper those look like the safe locales. In practice they carry a different failure mode: font coverage, not length.

Hebrew is the trap case in that table. It barely expands at all, sitting at 0%, so a length-only check would mark it as one of the safest locales you have. It still lands in our high-risk bucket, because the risk in Hebrew was never about character count.

Why right-to-left breaks the character-count heuristic entirely

Four of the 41 locales we track are right-to-left: Arabic, Hebrew, Persian, and Urdu. RTL is a layout mirror, not a text swap. The whole screen flips: image placement, progress indicators, back-arrow direction, even where the eye lands first on a screenshot. A field that measures character count and stops there will call Hebrew safe and ship a mirrored layout that nobody checked. If your screenshot localization process only validates string length, it has no way to catch this class of bug, because the string itself did not overflow anything. The layout around it did.

The font-coverage trap

Character-count headroom tells you nothing about whether the glyphs will render correctly. Latin, Cyrillic, and Greek scripts are usually covered by one well-built font family, so English, Russian, and Greek localizations rarely need separate font work. CJK is different: a generic font stack falls back to Chinese-style glyph shapes for Han characters shared across Chinese, Japanese, and Korean, and that reads as visibly wrong to Japanese and Korean readers even when every character is technically present. Arabic, Hebrew, Devanagari, and Thai each need their own font with correct shaping rules, and Thai additionally needs taller line-height to leave room for its stacked vowel marks and tone marks above and below the baseline. Budget font QA as its own line item per script family, not as a side effect of the translation invoice.

How to design copy that survives all 41 locales

Design against the worst-case locale, not the English source and not the average. German is your ceiling for expansion. If your English app name is 26 characters, it fits the 30-character cap without edits in only 10 of the 41 locales we track. Trim the English source to 20 characters and it fits all 41, with no per-locale rewrites and no rejected submissions to chase down after the fact. That single check, run before you send anything to a translator, replaces a round of post-translation firefighting with five minutes of arithmetic. We built localesThatFit(sourceLength, limit) as a small pure function against this exact dataset for that reason: give it your source string length and the field limit, and it tells you how many of the 41 locales will need a rewrite.

In practice that turns into a short workflow, not a one-off calculation:

• Write the English source short first. Every character you trim from the English string buys headroom in all 41 locales at once, not just one.
• Check the length against the worst case before translating. Run the source length against German's +35% before you send anything to a translator, not after.
• Flag RTL and CJK separately from the length check. Length clears Hebrew and Arabic incorrectly and clears Chinese, Japanese, and Korean without ever checking font coverage.
• Re-check after translation, not just before. Translators optimize for meaning and voice, not for a hard character cap, and the best translation for a locale is sometimes a few characters over.

None of this requires new tooling if you already have the source data. The dataset behind this post is a plain array of 41 records, each with an expansion percentage, a script family, and an RTL flag, and the entire "will this fit" question reduces to one multiplication and one comparison per locale.

Free checker

We turned this dataset into a free tool: the App Store Localization Checker. Paste your app name or subtitle, and it flags every locale where your translation is projected to overflow, before you pay for translation. It ships as an HTML page, an embeddable widget, and machine-readable JSON and CSV exports, all under the MIT license. It draws from the same field limits as our App Store character limits reference, so the two pages never disagree with each other about the same number. If you want the revenue case for doing this work at all, we cover that separately in why App Store localization moves revenue for indie developers, and if you are mapping locale codes between platforms, see our breakdown of iOS .lproj codes versus Android values-locale codes.

FAQ

How much longer does App Store copy get when translated?
It depends on the language, and the spread is wide. German runs about 35% longer than English in our dataset, the worst case we track. Portuguese, Polish, Finnish, and Hungarian sit around 30% longer. Most of Western Europe runs 20% to 25% longer. The CJK languages go the opposite way: Chinese is roughly 50% shorter by character count, Japanese 45% shorter, Korean 40% shorter, though each character reads visually wider on screen. Of the 41 App Store languages in the dataset, 35 expand and 5 contract.

Why does a 26-character app name fail in German specifically?
The App Store name field caps at 30 characters in every locale, and that cap applies per locale, not per app. A 26-character English name projects to roughly 35 characters at German's +35% expansion, which overruns the field. App Store Connect will reject that translation as submitted, and you end up shortening the German name on its own, separately from every other locale. This is one of the most common indie localization rejections, and the dataset makes it predictable before you commission a single translation.

Which languages need a mirrored, right-to-left layout?
Four of the 41 tracked languages: Arabic, Hebrew, Persian, and Urdu. RTL is a full layout mirror, covering image placement, progress direction, and back-arrow direction, not just a text direction swap. Hebrew is the trap to watch for specifically. It barely expands in character count, so a length-only check calls it safe while the layout still needs the full mirror treatment.

Do I need a separate font for every language?
You need coverage per script family, not per language. One solid font family usually covers Latin, Cyrillic, and Greek together. CJK needs its own font build, since a generic font falls back to Chinese-style glyph shapes for characters shared across Chinese, Japanese, and Korean. Arabic, Hebrew, Devanagari, and Thai each need dedicated fonts with correct shaping, and Thai needs extra line-height on top of that for its vowel and tone marks.

Is this expansion and overflow data free to use?
Yes. The checker and the underlying dataset are free, with JSON and CSV exports under the MIT license and attribution appreciated. It comes from the same per-language research behind our individual localization guides, so the numbers in this post, on the checker, and on each language-specific guide stay in agreement instead of drifting apart over time.