The Short Answer
If you opt into tablet distribution on Google Play, you need at least one screenshot rendered for the tablet form factor. Not a stretched phone screenshot — an actual tablet-layout capture.
The sizes to work to are 1200 x 1920 for 7-inch tablets and 1600 x 2560 for 10-inch, and you can upload up to eight per device type. Google recommends at least four tablet screenshots if you want to be eligible for large-screen recommendation surfaces, at 1080px or above in 16:9 horizontal or 9:16 vertical form.
The part people underestimate is that stretched phone assets get flagged in store quality reviews. It's visually obvious — text sits at phone scale inside a tablet frame, and the layout has phone-sized margins on a much wider canvas.
So this is one of those requirements where doing it properly takes a morning and skipping it costs you placement. Here's the whole thing.
The sizes to work to are 1200 x 1920 for 7-inch tablets and 1600 x 2560 for 10-inch, and you can upload up to eight per device type. Google recommends at least four tablet screenshots if you want to be eligible for large-screen recommendation surfaces, at 1080px or above in 16:9 horizontal or 9:16 vertical form.
The part people underestimate is that stretched phone assets get flagged in store quality reviews. It's visually obvious — text sits at phone scale inside a tablet frame, and the layout has phone-sized margins on a much wider canvas.
So this is one of those requirements where doing it properly takes a morning and skipping it costs you placement. Here's the whole thing.
Why Google Cares About This Now
Large screens stopped being a rounding error. Foldables, Chromebooks running Android apps and a genuinely large tablet install base mean a meaningful share of Play traffic is not a phone.
Google's response was to build recommendation surfaces specifically for large-screen devices, and to gate access to them on whether your listing has proper assets. If your store entry only has phone screenshots, you don't appear in those surfaces.
There's also a quality signal at work. An app whose listing shows stretched phone screenshots implies an app whose UI is also stretched, and reviewers apply that inference.
The practical effect is that tablet assets moved from optional to a distribution decision. Producing them is now part of shipping to large screens, alongside actually testing the layout — and an app that genuinely looks wrong on a tablet can't be fixed with better screenshots anyway.
Google's response was to build recommendation surfaces specifically for large-screen devices, and to gate access to them on whether your listing has proper assets. If your store entry only has phone screenshots, you don't appear in those surfaces.
There's also a quality signal at work. An app whose listing shows stretched phone screenshots implies an app whose UI is also stretched, and reviewers apply that inference.
The practical effect is that tablet assets moved from optional to a distribution decision. Producing them is now part of shipping to large screens, alongside actually testing the layout — and an app that genuinely looks wrong on a tablet can't be fixed with better screenshots anyway.
The Sizes You Actually Need
Play splits tablets into two groups and you upload separately for each.
7-inch tablets take 1200 x 1920 pixels in portrait. 10-inch tablets take 1600 x 2560. Both accept horizontal captures at the transposed dimensions, and going wide is often the better choice because it's how people hold tablets for media and productivity apps.
The broader constraint is that each side should sit between 320 and 3840 pixels, and Google's large-screen recommendation criteria want at least 1080px on the short edge — so working at the sizes above keeps you comfortably inside both.
Up to eight screenshots per device type, minimum one if you opt into that form factor. I'd do four, because that's the threshold for the recommendation surfaces and because four is enough to tell a story.
Formats are PNG or JPEG with no transparency, same as everywhere else on Play. If you're refreshing the phone assets at the same time, our Play Store screenshot sizes guide covers those dimensions.
Google documents the current asset requirements in its Play Console graphic assets reference, and it's worth checking before each release because the large-screen criteria have moved twice in two years.
7-inch tablets take 1200 x 1920 pixels in portrait. 10-inch tablets take 1600 x 2560. Both accept horizontal captures at the transposed dimensions, and going wide is often the better choice because it's how people hold tablets for media and productivity apps.
The broader constraint is that each side should sit between 320 and 3840 pixels, and Google's large-screen recommendation criteria want at least 1080px on the short edge — so working at the sizes above keeps you comfortably inside both.
Up to eight screenshots per device type, minimum one if you opt into that form factor. I'd do four, because that's the threshold for the recommendation surfaces and because four is enough to tell a story.
Formats are PNG or JPEG with no transparency, same as everywhere else on Play. If you're refreshing the phone assets at the same time, our Play Store screenshot sizes guide covers those dimensions.
Google documents the current asset requirements in its Play Console graphic assets reference, and it's worth checking before each release because the large-screen criteria have moved twice in two years.
Doing It Right vs Faking It Badly
The wrong way is to take a phone screenshot and scale it to tablet dimensions. Everything grows — text, buttons, padding — and the result looks like a phone app viewed through a magnifying glass. That's exactly what gets flagged.
The right way is to run the app on a tablet emulator at the target resolution and capture the actual tablet layout. If your app has a responsive layout with a master-detail split on wide screens, that split is the thing worth showing, because it's the reason a tablet user would install.
If your app genuinely has no tablet layout and just scales up, you have a product problem rather than a screenshot problem. Showing it honestly is still better than faking it, and users leave reviews about stretched interfaces regardless of what the store page implied.
Once you have real captures, dropping them into tablet device frames makes the listing look considered — that's what PlayMockup's frame library is for, and it takes minutes rather than an afternoon in a design tool.
The right way is to run the app on a tablet emulator at the target resolution and capture the actual tablet layout. If your app has a responsive layout with a master-detail split on wide screens, that split is the thing worth showing, because it's the reason a tablet user would install.
If your app genuinely has no tablet layout and just scales up, you have a product problem rather than a screenshot problem. Showing it honestly is still better than faking it, and users leave reviews about stretched interfaces regardless of what the store page implied.
Once you have real captures, dropping them into tablet device frames makes the listing look considered — that's what PlayMockup's frame library is for, and it takes minutes rather than an afternoon in a design tool.
Foldables and Awkward Aspect Ratios
Foldables are the genuinely tricky case because they're two devices in one. Folded, you're at a tall narrow phone ratio. Unfolded, you're near square — and near-square is the aspect ratio that breaks layouts designed for either extreme.
Play doesn't have a separate foldable screenshot slot. Foldables read your tablet assets when unfolded, so the 7-inch tablet group is effectively your foldable group too.
What that means in practice: capture at the unfolded resolution of a common foldable and check that your layout doesn't leave enormous empty columns. Near-square screens punish layouts that assume a tall canvas.
The other foldable-specific issue is continuity — what happens when a user unfolds mid-session. That's not a screenshot concern, though it is worth showing the unfolded state in at least one asset if your app handles it well, because it signals that you thought about the device.
Play doesn't have a separate foldable screenshot slot. Foldables read your tablet assets when unfolded, so the 7-inch tablet group is effectively your foldable group too.
What that means in practice: capture at the unfolded resolution of a common foldable and check that your layout doesn't leave enormous empty columns. Near-square screens punish layouts that assume a tall canvas.
The other foldable-specific issue is continuity — what happens when a user unfolds mid-session. That's not a screenshot concern, though it is worth showing the unfolded state in at least one asset if your app handles it well, because it signals that you thought about the device.
What to Actually Show
Tablet screenshots shouldn't be the phone set with more pixels. The extra width lets you show something the phone assets can't.
Multi-pane views are the obvious win. A list on the left and detail on the right in one frame communicates the app's structure instantly, and it's the single strongest argument for installing on a tablet.
Wide content — video, drawing canvases, spreadsheets, reading views — belongs in horizontal assets rather than portrait ones. Play accepts both and there's no rule against mixing orientations across your set.
Keep captions larger than you think. A tablet screenshot gets displayed smaller relative to its resolution than a phone one, so text that reads fine at full size can disappear in the store carousel.
The general principles from our guide to screenshots that get downloads still hold — first frame does the heavy lifting, one idea per screenshot — they just have more room to work with.
Multi-pane views are the obvious win. A list on the left and detail on the right in one frame communicates the app's structure instantly, and it's the single strongest argument for installing on a tablet.
Wide content — video, drawing canvases, spreadsheets, reading views — belongs in horizontal assets rather than portrait ones. Play accepts both and there's no rule against mixing orientations across your set.
Keep captions larger than you think. A tablet screenshot gets displayed smaller relative to its resolution than a phone one, so text that reads fine at full size can disappear in the store carousel.
The general principles from our guide to screenshots that get downloads still hold — first frame does the heavy lifting, one idea per screenshot — they just have more room to work with.
A Workflow That Doesn't Take a Day
Here's the sequence I'd follow, and it fits into a morning.
Spin up a 10-inch tablet emulator at 1600 x 2560 and a 7-inch at 1200 x 1920. Capture four raw screens on each, choosing the screens that show off the wide layout rather than repeating the phone story.
Check the raw captures for the things that ruin a listing: placeholder text, a debug banner, an empty state, a notification you didn't mean to include. Our note on capturing clean app screenshots covers the pre-capture checklist.
Drop each capture into a matching device frame and add a short caption. One line, six words or fewer, describing what the screen does rather than what it is.
Export as PNG without transparency and upload to the right device group in Play Console. Getting the group wrong is a common and quietly damaging error, because a phone-sized asset in the tablet slot is precisely the stretched look you were avoiding.
If you want the framing and captioning done in one pass, PlayMockup handles the whole set at once.
Spin up a 10-inch tablet emulator at 1600 x 2560 and a 7-inch at 1200 x 1920. Capture four raw screens on each, choosing the screens that show off the wide layout rather than repeating the phone story.
Check the raw captures for the things that ruin a listing: placeholder text, a debug banner, an empty state, a notification you didn't mean to include. Our note on capturing clean app screenshots covers the pre-capture checklist.
Drop each capture into a matching device frame and add a short caption. One line, six words or fewer, describing what the screen does rather than what it is.
Export as PNG without transparency and upload to the right device group in Play Console. Getting the group wrong is a common and quietly damaging error, because a phone-sized asset in the tablet slot is precisely the stretched look you were avoiding.
If you want the framing and captioning done in one pass, PlayMockup handles the whole set at once.
Testing the Layout Before You Capture
There's no point producing beautiful tablet screenshots of a layout that doesn't work. Ten minutes of testing first saves you from advertising a problem.
Run the app on a 10-inch emulator and look for the three usual failures. Single-column layouts stretched to full width, so a line of body text runs 140 characters and becomes unreadable. Buttons pinned to the bottom of a tall canvas, miles from where a thumb rests. And dialogs that fill the whole screen because they were sized as a percentage.
Android's window size classes are the framework answer to this, and they're worth adopting even if you only ever ship one tablet breakpoint.
Once the layout genuinely adapts, the screenshots write themselves — you photograph the thing that's now obviously better on a big screen. If it doesn't adapt, no amount of framing hides it, and tablet users say so in reviews within a week.
I'd rather ship phone-only distribution honestly than opt into tablets with a stretched layout and a listing that oversells it.
Run the app on a 10-inch emulator and look for the three usual failures. Single-column layouts stretched to full width, so a line of body text runs 140 characters and becomes unreadable. Buttons pinned to the bottom of a tall canvas, miles from where a thumb rests. And dialogs that fill the whole screen because they were sized as a percentage.
Android's window size classes are the framework answer to this, and they're worth adopting even if you only ever ship one tablet breakpoint.
Once the layout genuinely adapts, the screenshots write themselves — you photograph the thing that's now obviously better on a big screen. If it doesn't adapt, no amount of framing hides it, and tablet users say so in reviews within a week.
I'd rather ship phone-only distribution honestly than opt into tablets with a stretched layout and a listing that oversells it.
Frequently asked questions
Are tablet screenshots mandatory on Google Play?
They're required if you opt into tablet distribution — Google asks for at least one screenshot per targeted device group. If you want eligibility for large-screen recommendation surfaces, aim for at least four at 1080px or above.
What size should Play Store tablet screenshots be?
1200 x 1920 pixels for 7-inch tablets and 1600 x 2560 for 10-inch, in portrait, with the transposed dimensions if you go horizontal. PNG or JPEG, no transparency, up to eight per device type.
Can I just stretch my phone screenshots for tablets?
No, and it's visually obvious — text and padding scale up together, so it looks like a magnified phone app. Stretched assets get flagged in store quality reviews and undermine the impression that your app supports large screens.
Do foldables need their own screenshots?
Play has no separate foldable slot. Foldables read your tablet assets when unfolded, so the 7-inch tablet group covers them. Capture at a common unfolded resolution and check your layout doesn't leave big empty columns on a near-square screen.
How many tablet screenshots should I upload?
Four is the practical target — it's the threshold Google mentions for large-format recommendation surfaces and it's enough to show a multi-pane layout properly. Dropping them into [tablet device frames](/frames) makes the set look deliberate rather than an afterthought.
Build the mockup in your browser.
Drop a screenshot into a real device frame and export at the exact store size — free, no signup.