How to Translate App Store Screenshots

Translate a finished set, not a draft. Every change to the English source after translation multiplies into one change per language, so lock the order, captions and app states first.

• Final source screenshots, one per slide, captured at the largest iPhone size you ship. Apple lets you upload one to 10 screenshots (opens in a new tab) per device size, and the first one to three can appear in search results when no app preview is available, according to Apple's product page guidance (opens in a new tab).
• A string list or glossary with product names, feature names and terms that must stay in English. This stops the same button being translated three different ways across slides.
• Real app states captured in the target language, where possible. If your app is already localized, a native simulator capture is the most accurate source for the UI inside the screenshot.
• A reviewer per language, even if it is a colleague or a customer who reads it natively.

A practical example: a habit tracker with six slides picks its 6.9-inch set (1320 × 2868) as the source. Apple accepts 1320 × 2868, 1290 × 2796 and 1260 × 2736 (opens in a new tab) for the 6.9-inch slot, and smaller iPhone sizes can scale down (opens in a new tab) from the highest resolution you provide.

Start with the markets where you already see downloads, reviews or support email in another language. Then map each language to the exact code each console uses, because the two stores do not share one list.

Apple documents its App Store Connect locale shortcodes (opens in a new tab), and Google lists store listing languages in Play Console Help (opens in a new tab). StoreLocale labels its export folders with short codes such as ja or zh, so keep this mapping next to your upload checklist.

Where a store splits a language into regional variants, decide which one your screenshots target. StoreLocale produces one generic Portuguese and one generic Spanish variant, so read them against the market you upload to. The locale codes guide covers every mapping in detail.

Captions are the headlines above or around the device; in-app UI is the text inside the captured screen. Translating only captions is faster, but a Japanese caption above English buttons still tells the viewer the app may not speak their language.

Google's own guidance draws a line here: Play Console Help (opens in a new tab) says in-game UI does not need to be localized per market, but taglines and text overlays should be. For productivity, finance, health and utility apps, the UI is the product, so translating it usually matters more than for a game.

Only translate UI text into a language the shipped app actually supports. The caption vs in-app UI guide goes deeper on the trade-off.

StoreLocale detects the text inside each screenshot, translates it, and then repaints the screenshot with the translated strings in place. Detection and translation cost 0 credits; only the repaint uses credits.

1. Upload the source set. Add PNG, JPEG, WebP or GIF screenshots in one go; each file becomes a slide, and duplicate uploads are skipped. Keep the canvas on the iPhone 6.9-inch format for App Store sets.
2. Add your captions and frame. Place headline text layers and a device frame per slide. Caption text can be set per locale, so you can shorten a German headline without touching the English one.
3. Pick target languages. Choose from 32 target languages, including Simplified and Traditional Chinese and the right-to-left languages Arabic and Hebrew.
4. Detect UI text. Run Detect text on one slide or on the batch. A vision model returns every UI string with its position, grouping wrapped headlines into one phrase and skipping the status bar.
5. Review and edit strings. Check the translated strings for each locale before generating. Brand names and acronyms such as PRO or 4K stay untranslated, and you can overwrite any string by hand.
6. Generate the localized asset. Pick a quality tier: Standard (1 credit, 1K), Pro (2 credits, 2K) or Ultra (4 credits, 4K). Batches run two jobs at a time, and unchanged assets are reused without a new charge.
7. Compare side by side. Use the split view to put the source slide next to the localized one and look for anything the repaint changed that it should not have.

Prefer your own model account? With a personal OpenRouter or Gemini API key (BYOK), generations use 0 platform credits; the key is stored in your browser. Credit pack prices are listed on the pricing page.

Layout problems are easy to miss, so review each image at full size and at thumbnail size; the first slides are often seen small in search.

• Text length. Short strings grow the most. The W3C's text size article (opens in a new tab) cites IBM guidance of 200–300% average expansion for English source text up to 10 characters, which is exactly the length of a button label.
• Visual width in CJK languages. Japanese, Chinese and Korean can use fewer characters yet take more horizontal space, as the W3C notes with the example of "desktop" in Japanese.
• Line breaks. Look for orphaned single words, hyphenation in the wrong place, and headlines that now wrap to three lines. Shorten the copy rather than shrinking the font below readable size.
• Terminology. Button and tab names in the screenshot should match what the localized app really shows. Cross-check against your app's string files or a native capture.
• Right-to-left layout. In Arabic and Hebrew, confirm reading order, punctuation position and number direction, and decide whether mirrored UI matches your shipped app. The RTL screenshot guide lists the checks.
• Untouched content. Prices, dates, ratings, charts and user-generated content should stay correct for the market or be left alone deliberately.

A worked example from the W3C (opens in a new tab): the English word "views" becomes a German phrase about 2.8 times the length. If a German caption wraps, rewrite it as a shorter phrase in the German caption layer rather than shrinking the font. The text expansion guide has more language-by-language patterns.

Export produces one ZIP of PNG files for every selected language and size. Folders follow the pattern Platform / locale / size, so the Japanese 6.9-inch set lands in a path like App Store (iOS)/ja/iphone-6-9/01-track-habits.png.

• Platform folders: App Store (iOS), Google Play, Desktop & Social, and Original.
• File names: numbered by slide order (01, 02…), or kept as your original file names if you choose that option.
• Strict export: slides with untranslated text or unfinished localized assets can be skipped or blocked, so an incomplete language does not slip into the ZIP.

Every size is scaled from a fixed 1320 × 2868 portrait base. That makes the iPhone 6.9-inch preset the most reliable output; other presets with different proportions, such as iPad or Android sizes, can stretch, so check them before upload. Apple accepts .png, .jpg and .jpeg without alpha channels or transparency (opens in a new tab), so use an opaque background and, if a console rejects a file, re-save it without an alpha channel.

Uploading is manual; StoreLocale does not connect to App Store Connect. Apple's upload help page (opens in a new tab) is the reference for the current screens.

1. Open your app version in App Store Connect and switch to the localization you are updating, for example Japanese.
2. Drag the PNG files from that locale's iphone-6-9 folder into the 6.9-inch iPhone slot, in slide order.
3. Repeat per locale. Apple says that if your UI is the same across sizes and localizations, you can provide only the highest resolution screenshots and they scale down; use Media Manager when you want specific screenshots per size or localization.
4. Submit the screenshots with the next version, together with the localized description and keywords.

Apple's guidance is to localize your app description, keywords, app previews and screenshots (opens in a new tab) for each market where you offer the app, so plan the text metadata in the same pass.

In Play Console, add the language to your store listing, then add graphics for that language. Google notes (opens in a new tab) that if you don't localize graphic assets, the default language's graphics are shown instead.

• Google Play accepts JPEG or 24-bit PNG without alpha (opens in a new tab), with each side between 320 px and 3840 px.
• The longer side cannot be more than twice the shorter side. A 1320 × 2868 iPhone export is taller than 2:1, so it will not pass as a Play phone screenshot.
• StoreLocale's Play phone presets do not fix this: the 1080 × 2400 Modern Phone preset also exceeds the 2:1 limit, and the 1080 × 1920 Standard Phone preset is stretched from the 1320 × 2868 portrait base. Inspect every Play export, and prepare Play phone screenshots separately if the result is distorted.
• You need at least two screenshots across device types to publish, and Google recommends at least four at 1080 px or more for recommendation placements.
• Google also advises that taglines should not take up more than 20% of the image.

Treat a new screenshot set as a hypothesis. Both stores offer built-in testing that can be scoped to specific languages, which is the cleanest way to see whether localized visuals change conversion.

• App Store: product page optimization (opens in a new tab) compares icons, screenshots and app previews. A test can include up to three treatments, and each treatment can be localized in all or selected languages.
• Google Play: store listing experiments (opens in a new tab) support localized experiments on the icon, feature graphic, screenshots and descriptions in up to five languages.

Results vary by app, so avoid borrowing someone else's uplift as a forecast. One reference point: Google's Koo case study (opens in a new tab) reports a 15% rise in organic installs in non-English languages after the team tailored custom store listings, including screenshots, for those markets.