App Store Screenshot Translation: 6 Caption Mistakes [2026]

Translating App Store screenshots is not the same as translating your metadata. The caption text sits baked inside the image, so you can't edit it after upload, it's boxed into a fixed space that a longer language overflows, and it has to match the app a reviewer actually opens in that language. Get any of those wrong and you either lose installs or fail review.

That gap is where the damage happens. Your title, subtitle, and keyword field are editable text fields, and the complete localization guide covers how to translate those. This one is only about the words painted onto the screenshots, and the six ways a machine translation quietly breaks them. Each mistake below comes with the fix, and two of them come with the exact App Store Review Guideline that turns a sloppy caption into a rejection.

TL;DR:

• Screenshot captions are image text, not metadata. They can't be hot-fixed, they're space-constrained, and they must match the localized app, so the translation rules are stricter than for your keyword field.
• The most expensive mistake is a caption that names a feature by a word your localized app doesn't use. Guideline 2.3 says screenshots must "accurately reflect the app's core experience" [1].
• Machine translation gets you the literal words. A converting hook needs transcreation: a different sentence in the target language that lands the same way, not a word-for-word swap.
• Short marketing strings expand the most in translation (200-300% for sub-10-character English) [3], so headlines break layouts that body copy survives.
• If you add a locale but skip its screenshots, Apple shows your primary-language set instead [2], so shoppers see English captions on a German store page.

Table of contents

• Is translating a screenshot different from translating metadata?
• Does your caption match the words your app actually uses?
• Did you translate the hook, or transcreate it?
• Will the translated text still fit the layout?
• Are the numbers, currency, and dates localized too?
• Are users seeing translated captions on the wrong screenshots?
• Is the translated caption still legible?
• How to translate screenshots without the mistakes

Is translating a screenshot different from translating metadata?

Yes, and treating them the same is the root mistake. Metadata (your title, subtitle, keyword field, and description) is editable text that Apple stores as strings. A screenshot caption is pixels inside a JPEG or PNG. That single difference changes every rule: you can fix a bad keyword in a metadata-only update, but a bad caption means re-rendering and re-uploading the whole image set, which is cheap when a screenshot builder regenerates the localized set from one design and expensive when you're rebuilding each image by hand.

Three constraints follow from caption text being image text. First, it's permanent until you re-export, so a mistranslation ships until the next build cycle instead of the next save. Second, it lives in a fixed container, so a language that runs long doesn't just read awkwardly, it clips or wraps into the device frame. Third, it sits on top of a screenshot of your app, so the caption and the interface underneath it have to agree. Metadata carries none of those constraints, which is why the metadata localization workflow and this caption workflow are genuinely separate jobs. If you're only aware of one set of rules, it's usually the metadata set, and the caption set is where the avoidable rejections hide. For the definitional overview, see screenshot localization.

Does your caption match the words your app actually uses?

This is the mistake that costs a rejection, not just conversion. A machine translation renders your English caption into the target language in isolation, with no idea what your app's own localized interface calls that feature. So your German caption might promise "Sofortüberweisung" while the app's German UI labels the same button "Direktzahlung." The words disagree, and App Review notices.

Apple's rule is explicit. Guideline 2.3 (Accurate Metadata) states that "all your app metadata, including privacy information, your app description, screenshots, and previews accurately reflect the app's core experience" [1]. Guideline 2.3.1 escalates it: "marketing your app in a misleading way, such as by promoting content or services that it does not actually offer" is grounds for removal [1]. A caption that names a feature the localized app doesn't offer under that name is exactly the mismatch a reviewer opens the build to check. The fix is to translate captions against your app's own localized string file, not against the English source in a vacuum. Whoever writes the caption copy should have the app's target-language UI strings open beside them, so the caption reuses the same term the interface uses. This is also where caption text and your keyword field should agree: reinforcing the same localized term across both is the point of a coherent screenshot keyword strategy.

Did you translate the hook, or transcreate it?

Machine translation gives you the literal words. A converting headline needs transcreation, which is a different sentence in the target language that lands the same emotional hit, not a word-for-word swap. "Crush your goals" translated literally lands somewhere near "zerstöre deine Ziele" in German, which reads like a threat, not motivation. The meaning survived and the persuasion died.

Marketing copy is the worst case for literal translation because its power comes from idiom, rhythm, and cultural reference, none of which map one-to-one across languages. A caption is your highest-value copy on the store page, so it's the last place to run raw machine output. The fix isn't to abandon machine translation entirely, it's to treat it as a first draft and have a native speaker rewrite the hook for impact, not accuracy. The standard localization advice for the subtitle field is to avoid machine translation and hire a native speaker for tone, and your caption headlines deserve the same bar, because the stakes are higher when the text is locked into the image. The body caption under the hook tolerates a more literal treatment; the headline almost never does.

Will the translated text still fit the layout?

Usually not, and shorter captions break worst. Translated text rarely matches the source length, and the W3C's guidance is blunt: "the smaller the source message, the higher the likely translation length" [3]. English strings under 10 characters can expand 200-300% into European languages [3]. Screenshot headlines are short strings, so a headline that fits perfectly in English can overflow the safe area, clip against the device frame, or wrap into a third line the layout never planned for.

This is the mistake designers see immediately and still underestimate, because they test with English and assume a 30% buffer covers it. It doesn't, for the shortest and most important strings. The per-language, per-layout engineering (which layouts absorb expansion, which collapse, and how to redesign the English source so the translated render survives) is its own deep topic, worked through in detail in the German text-expansion guide. The short version for any language: design the English source with headroom you'll never use in English, so the German, Finnish, or Russian render has somewhere to grow.

Are the numbers, currency, and dates localized too?

Almost always missed. When you translate a caption's words but leave "$4.99", "12/25/2026", or "1,000,000 users" untouched, the caption reads as half-localized, which signals a rushed job to exactly the local users you're trying to convert. A stat caption showing US-formatted numbers to a German shopper (who expects "4,99 €" and "25.12.2026") quietly undercuts the trust the screenshot is supposed to build.

The formats that need adapting inside caption graphics: currency symbol and position, decimal and thousands separators (comma versus period flip between locales), date order (DD/MM/YYYY, MM/DD/YYYY, YYYY/MM/DD), and units. If your caption leans on a proof number ("Save $200 a year"), that number has to be both formatted and plausible for the market, since local price points differ. The fix is a per-locale pass on every numeric element in the caption, not just the words around it. Treat the number as copy that needs translating, because to the reader it is.

Are users seeing translated captions on the wrong screenshots?

This one is invisible until you check the live listing. If you add a language to your App Store product page but don't upload a screenshot set for it, Apple doesn't leave a gap. Its documentation states that when you add a language, "screenshots and the properties for the new language default to those of the primary language" [2]. So your carefully translated title sits above your original English screenshots, and the shopper sees a half-translated page.

The reverse trap is just as common: you upload beautifully translated captions, but the screenshots underneath still show your app in English because you rendered them from an English build. Guideline 2.3.3 says "screenshots should show the app in use" [1], and a German caption over a visibly English interface is neither accurate nor convincing. The fix is to confirm two things per locale before you submit: a dedicated screenshot set exists for that language (so the fallback [2] never triggers), and the interface captured inside those screenshots is running in the target language, not just the caption on top of it. Preview every localized set in App Store Connect, because that's the only place you'll catch the fallback and the English-UI-under-translated-caption traps before your users do.

Is the translated caption still legible?

Easy to break, easy to fix. A translation that fits the character count can still fail on legibility: a longer string forces a smaller font, an accented character (ö, ñ, ç) collides with a tight line, or a script your chosen font doesn't fully support renders as fallback boxes. And the visible text in your screenshots is machine-readable, which is why legibility isn't only a human concern, it's how the text gets parsed too, as the Apple OCR indexing breakdown explains.

Two checks catch most of it. First, confirm your caption font actually supports the target language's full character set, including accents and, for languages like Arabic or Hebrew, the right-to-left shaping rules that a Latin font ignores. Second, view the localized screenshot at the size it's actually seen: the App Store thumbnail and search-result strip are small, so a caption that's readable at full size can turn to mud once it's translated into a longer, denser string. If you can't read the translated caption in the search-result preview, neither can the shopper deciding whether to tap.

How to translate screenshots without the mistakes

Accurate screenshot translation comes down to one principle: the caption, the interface under it, and the app itself all have to speak the same language, in the same words, at a size people can read. That's more than running headlines through a translation API and dropping the output into a template. Machine translation is a fine first draft and a poor final copy.

Run the checklist per locale: translate captions against your app's own localized UI strings, transcreate the hook instead of translating it literally, design the English source with expansion headroom, localize every number and currency and date inside the graphic, upload a real screenshot set so Apple's primary-language fallback never fires, and preview the result at thumbnail size. The production bottleneck is regenerating the full set per language without rebuilding each design by hand. A chat-based screenshot builder can swap the caption language across an existing set and re-render, so the fix for a bad translation is another turn, not another afternoon in a design tool. Get the words right against the app first, then let the tool carry them across the set.