A screenshot caption should state a benefit in three to six words, sit at the top of the frame where it is read before the interface, and use sentence case at a size readable in a thumbnail. Lead with the outcome the user wants rather than the feature name. The first two captions carry nearly all the weight, because most people never scroll past them.
Why do bare screenshots underperform?
An uncaptioned screenshot asks the user to do work. They have to look at an interface they've never seen, identify what it does, and infer why they'd want it, in roughly a second and a half.
Most people won't. They'll scroll.
That's the entire argument for captions, and it's why "just show the app" is bad advice for utilities even though it's correct for games. I went into that split separately in the game versus utility comparison, and it's worth being sure which category you're in before you follow anything here.
For everything sold on solving a problem, the caption is doing more conversion work than the screenshot underneath it.
Benefit or feature?
"Advanced OCR engine" is a feature. "Scan any receipt in a second" is a benefit. Same screenshot underneath, completely different response.
The reason this works isn't a copywriting trick. The user has a problem and is scanning for evidence you solve it. A feature name is only meaningful if they already know why that feature matters, which is a lot to assume.
A quick test I use: put "so you can" after your caption and see if a sentence follows. "Advanced OCR engine, so you can..." has an obvious missing half. If it does, the thing after "so you can" is your actual caption.
Some more before and after pairs:
"Cloud sync enabled" becomes "Your notes on every device".
"Customisable widgets" becomes "See today at a glance".
"Bank grade encryption" becomes "Nobody sees your data, not even us".
That last one is worth dwelling on. It's longer than my recommended limit and it earns the extra words because trust is the deciding factor in that category. Rules are defaults, not laws, and if your differentiator needs eight words then use eight.
One exception in the other direction: if your audience is technical and searching for a specific capability, the feature name *is* the benefit. A developer looking for a Kubernetes client wants to see "Multi-cluster context switching", not "Manage everything easily".
How many words actually fit?
Your screenshot is being viewed at maybe 200 pixels wide in search results. At that size, caption text needs to be proportionally large, which means fewer words. A seven word caption sized to fit becomes unreadable at thumbnail size, and an unreadable caption is worse than none because it adds visual noise without communicating.
The practical check, which almost nobody does: export your screenshot, scale it to 200 pixels wide, and look at it on a phone at arm's length. If you can't read the caption, it's too long or too small. This takes thirty seconds and it's the single highest value thing in this article.
Two lines maximum. Three lines of caption starts eating the interface you're trying to show.
Sentence case reads faster than Title Case, and full caps is slowest of all. Caps also takes more horizontal space per character, so you get fewer words for the same width. There's no upside.
Punctuation mostly hurts. Full stops at the end of a three word caption add nothing. Exclamation marks read as desperate.
Localisation is where word count becomes a hard constraint rather than a guideline. German and Russian commonly run 30 percent longer than English, and Finnish can be worse. If you're shipping to multiple markets, design the caption area for the longest language and let English look slightly generous, rather than designing tight for English and breaking everything else. Google's preview asset guidance is worth checking alongside that, since the asset rules differ per store.
Where should the caption sit?
Reading order is top to bottom. Putting the caption above the phone means it's read before the interface, which is the sequence you want: tell them what they're about to look at, then show it.
A caption below the screenshot gets read after the user has already tried and failed to decode the interface, which defeats the purpose.
Give it room. Caption text crammed against the top edge or overlapping the device frame looks cheap and reduces contrast. A comfortable band of background above the device, with the caption sitting in it, is the layout that has become standard because it works.
Contrast matters more than colour choice. Dark text on a light background or light on dark, with a real difference between them. Mid-grey text on a mid-toned background is the most common readability failure I see, and it usually happens because the designer was matching a brand palette rather than checking legibility.
Keep the caption position identical across all frames. When the text jumps up and down between screenshots, swiping through feels unsteady and unprofessional. Consistency here is invisible when you get it right and obvious when you don't, which is exactly why keeping the frame fixed in the mockup studio and only changing the screen and the text is worth doing. The device frame library covers the frames themselves so the device never shifts between shots.
How do you know if a caption is working?
Both stores support proper simultaneous testing now, so you're not guessing or comparing across time periods with different traffic mixes. Change one thing, run it until the numbers separate, keep the winner.
Change one caption at a time. If you rewrite all five and conversion moves, you've learned that something helped, which is nearly useless for deciding what to do next.
Test the first caption before anything else. It sees the most eyes by a wide margin, so the same percentage improvement is worth more there than anywhere else in the listing.
Give it enough traffic. Small apps often can't reach significance on subtle changes in a reasonable time, and there's no shame in that. If you're low volume, test big swings rather than word choices, because only large effects will be visible.
What I'd do with a listing that's never been tested: write a benefit led caption for frame one, make sure it's readable at thumbnail size, keep everything else identical, and run it. That's the highest value single change available on most product pages, and it's free.
I've watched this go both ways. On one listing the benefit led caption beat the feature led one clearly and quickly. On another, the two were indistinguishable after weeks, and the honest conclusion was that the app's problem was the icon rather than the words. Both outcomes were useful, which is the argument for testing rather than arguing about copy in a meeting.
A note on patience. The temptation is to call a result after two days because one variant is ahead. Early leads reverse constantly, and stopping a test as soon as it says what you hoped is how teams convince themselves of things that aren't true.
If nothing moves, the problem is probably upstream of the copy. Weak visuals, wrong audience, or an app that genuinely doesn't stand out. Captions amplify a good listing rather than rescuing a bad one, and the design mistakes checklist is where I'd look next.
Frequently asked questions
How long should an app screenshot caption be?
Three to six words for most apps, over a maximum of two lines. That's a readability constraint rather than a style choice, because your screenshot appears at around 200 pixels wide in search and longer captions have to be set too small to read at that size.
Should captions describe features or benefits?
Benefits, in almost every case. Advanced OCR engine is a feature; scan any receipt in a second is a benefit. A useful test is adding so you can after your caption, and if a sentence naturally follows, that continuation is your real caption. Technical audiences searching for a specific capability are the exception.
Where should the caption go in a screenshot?
At the top of the frame, above the device, so it's read before the interface. Reading order runs top to bottom, so a caption underneath gets read after the user has already tried to decode the screen. Keep the position identical across every frame so swiping feels steady.
How do I check if my caption is readable?
Export the screenshot, scale it to about 200 pixels wide, and look at it on a phone at arm's length. If you can't read the caption, it's too long or too small. It takes thirty seconds and catches most caption problems before they ever reach the store.
Do captions need to change for different languages?
The layout does. German and Russian commonly run around 30 percent longer than English and Finnish can be worse, so design the caption area for your longest language rather than tight to English. Designing for the longest language and letting English look slightly generous is the habit that avoids rework later.
Which caption should I test first?
The first one, since it's seen by far more people than any other frame, so the same percentage improvement is worth more there. Change one caption at a time, because rewriting all of them at once tells you something helped without telling you what. Build the variants in the [studio](/create) so only the text changes between them.
Build the mockup in your browser.
Drop a screenshot into a real device frame and export at the exact store size — free, no signup.