App Store Screenshot Typography: Fonts, Sizes & Hierarchy (2026)

TL;DR. On the required 1290x2796 px iPhone canvas, set your headline at 56 to 72 px in a bold geometric sans (Inter, Manrope, DM Sans) at weight 700 to 900, and your subtitle at 28 to 36 px at a lighter weight 300 to 500. Use one typeface across all ten screenshots, never more than two to three styles per screen, and keep captions in the top ~25% so they survive the search thumbnail. The decisive test: if the headline is not readable shrunk to 200 px wide, it is too small or too wordy.

Last updated: 2026-08-06.

Disclosure. We make ScreenFast, an AI App Store screenshot generator. It fits at the apply-and-ship step after this guide teaches you the spec, and we name that step plainly. All px numbers refer to the 1290x2796 export canvas; we explicitly flag a conflicting "scale" floating around the web that would mislead you.

Which canvas your px numbers refer to (and why two scales conflict)

Before any number means anything, fix the canvas. Every px size in this guide is measured on the 1290x2796 px iPhone 6.9-inch export canvas, the actual file you upload.

This matters because two incompatible scales circulate online. The correct one (used by screenshototter, mobiloud) gives headlines of 56 to 90 px on that 1290 canvas. A second set of numbers you will see, like "headline 24 to 32 px, body 14 to 16 px," comes from web or in-app UI contexts with no canvas stated. Those would be illegibly tiny on a real screenshot. If a guide says "32 px headline" without naming a 1290 canvas, it is the wrong scale. Use the numbers below.

The four-rung hierarchy ladder (with real px)

A converting caption uses at most three of these four rungs.

The headline is the only rung that does the heavy lifting. The subtitle exists to separate from the headline by weight or muted color, not to add more reading. Body text does not belong on a screenshot; if you are reaching for it, cut words instead. The words themselves are a separate craft, covered in screenshot copywriting.

Which fonts convert: geometric sans, serif accents, and the SF Pro question

Clean geometric and neo-grotesque sans-serifs win. Decorative, script, and handwriting fonts lose at thumbnail scale.

• Headline sans (default): Inter, Manrope, DM Sans, Space Grotesk, Outfit, Sora. Classic safe picks: Helvetica, Roboto, Montserrat, Open Sans.
• Display serif (finance, travel, lifestyle, luxury): Playfair Display, Fraunces, DM Serif Display.
• High-impact (fitness, sports): Oswald (condensed), Archivo Black.
• Eyebrow chips: a mono like JetBrains Mono reads well in small caps.

On the SF Pro question developers always ask: do not use SF Pro for screenshot captions. Two reasons. It is tuned for legibility at 13 to 17 px UI, not for impact at 80 px. And Apple's font license largely restricts SF Pro to in-app UI, not marketing assets. A free geometric sans like Inter is both more impactful and license-clean for this use. Also avoid pairing two similar sans (Inter + DM Sans adds complexity without contrast), and skip the ultralight and thin weights, which vanish when downscaled.

How to create App Store screenshots in Figma shows the type styling in practice.

Legibility at thumbnail scale: the test that decides everything

This is the rule that overrides every other rule. About 96% of users never enlarge a portrait screenshot (mobiloud), so they only ever see it small. Your caption is seen at roughly 200 px wide in search results, 300 px in the product-page gallery, and full size only on a tap that almost never happens.

Two concrete tests:

1. The 200 px test. Shrink your screenshot to about 200 px wide and confirm the headline is still readable. That is the actual search-thumbnail width.
2. The 25% zoom test. Open the full 1290x2796 file and zoom to 25%. If you cannot read the headline instantly, increase the size or cut words.

Weight adapts to background. Drop one weight step on dark backgrounds (use 700, not 800), and bump to 800 to 900 on light ones. Fonts that survive downscaling share three traits: high x-height, open counters, and sturdy stems.

Word count, line length, and how many type styles per screen

Headlines are 2 to 6 words, ideally broken into two short lines. Subtitles are one line, two at most, and 8 to 12 words maximum; if a subtitle wraps to a second line at thumbnail size, it will not be read. The rule of thumb across sources: if it needs two reads, it is too long.

Limit yourself to two or three type styles per screen. Three or four different fonts on one screenshot reads as amateur. One typeface, two or three weights, across all ten screenshots, is the professional baseline.

Safe-area placement: where the caption goes

The upper portion of the screenshot is the most visible zone in search results, and the first two to three screenshots carry most of the conversion weight (Adapty notes about 90% of users do not scroll past them).

Keep your headline and subtitle in the top ~25 to 30% of the 1290x2796 canvas (a synthesized recommendation, not an Apple spec). Use side safe margins of roughly 96 to 120 px (about 7.5 to 9% of the width) so text never crowds the edge or gets clipped in rounded gallery thumbnails. Caption-above-device versus caption-below-device is a style choice, but above-device keeps the copy in the high-visibility top band.

Per-language and non-Latin typography (CJK, RTL)

Localized screenshots are an ASO lever, and type is where they quietly break. The screenshot-specific guides skip this entirely, so here is the substance.

Localize the font per locale, not just the text. Use region codes: SC (Simplified Chinese), TC (Traditional), JP (Japanese), KR (Korean). Simplified Chinese leans Song (serif) or Hei (sans). The de-facto open-source family is Noto Sans CJK (Source Han Sans), which ships SC, TC, JP, and KR cuts. Two gotchas: when you mix Latin and CJK at the same point size the Latin glyphs look too small and need a paired Latin font or optical up-scaling, and CJK's higher visual density makes the same px headline read heavier, so you may need to reduce size or weight (guidance, not a documented spec). For Arabic and Hebrew, right-align the caption and use a font with full RTL glyph coverage. The full localization flow is in the localization guide.

How we tested

The headline and subtitle ranges, font picks, and legibility tests come from the type-specialist sources in the SERP (chiefly screenshototter and AppMockUp), cross-checked for the canvas-scale conflict. The single most important correction here is that conflict: we use the 1290x2796 canvas scale and explicitly flag the smaller "24 to 32 px" numbers as a different, web-relative scale that does not apply. Conversion figures (good captions lift ~20%, ~96% never enlarge, ~7 second visit) are vendor-reported and directional; no source provides a controlled px-size-versus-conversion A/B number, so all px values are best-practice heuristics, not benchmarks. The CJK and safe-margin specifics are synthesized guidance, labeled as such. ScreenFast is our own product, named only at the apply step.

Applying the hierarchy without hand-setting type

If hand-setting four rungs of type in Figma is not how you want to spend an afternoon, this is the one place our tool fits. ScreenFast's design styles each bake in a coherent typographic treatment (headline weight, subtitle contrast, eyebrow chips) on the correct 1290x2796 canvas, so the hierarchy above is applied for you across 10 variants. You still write the words and check the 200 px test. See the AI App Store screenshot generator, or design by hand with the Figma template guide.

FAQ