How to export screenshots for Google Play Console

Choose the device types you support

Separate phone screenshots from tablet captures and other listing graphics. Use the dimensions accepted by the current Play Console workflow for each device type rather than resizing one image to every slot.

Export the feature graphic separately

The feature graphic has its own canvas and purpose, distinct from a screenshot. Keep its file, dimensions, and design checks separate from the phone and tablet export set.

Validate format, size, and content

Check the current accepted formats, pixel dimensions, file limits, and content rules in Play Console. Open exported files after saving to catch wrong orientation, blank exports, text clipping, or accidental transparency.

Upload and preview the listing

Use the Play Console asset fields for the matching device type, then preview the listing on relevant surfaces. Replace a rejected or awkwardly cropped asset before release and record which source file produced the final upload.

A pre-upload checklist

Before opening Play Console, group files by device type, verify pixel dimensions and orientation, open each export, and compare the artwork with the current app. Keep the feature graphic in its own clearly named file so it cannot be mistaken for a phone screenshot.

Use neutral filenames that identify locale, device, and sequence, for example `en-US-phone-01.png`. The exact folder naming is your team’s convention unless an upload tool requires a specific structure; the console slot assignment is what determines where an asset appears.

Diagnose a rejected or awkward asset

If an upload fails, compare the actual file properties with the current console message instead of resaving blindly. Check dimensions, file type, file size, and whether the image contains prohibited overlays or misleading claims.

If the upload succeeds but the listing looks wrong, inspect the device category and preview crop first. A valid image can still be assigned to the wrong slot or designed with important text too close to an edge.

Keep source files separate from upload exports

Maintain an editable source project and create a clean export folder for each release. This prevents a reviewer from uploading a draft, an outdated localization, or a working file with guides and hidden layers.

Use filenames that make the release easy to audit, such as locale, device, and sequence. Keep filenames descriptive even if the console ignores them; they are valuable when a rejected asset has to be replaced quickly.

Check the listing after processing

A successful upload only confirms that the console accepted a file. Preview the actual listing on the device categories you support and verify that the first image tells the right story at the size people see it.

Record the accepted export and its source. If the listing is updated again, compare the new asset to the published one so an unrelated design change does not slip into a requirements-only revision.

A sample export handoff

A release folder might contain `phone/en-US/01.png`, `phone/en-US/02.png`, `tablet-7/en-US/01.png`, and a separate `feature-graphic/en-US.png`. The exact structure can follow your team’s workflow; keep the distinction between device assets obvious.

Before uploading, compare the export folder with a short manifest listing dimensions, locale, and intended Play Console section. This catches a wrong file assignment faster than opening each image after the upload.

Confirm the current rules at submission time

Google can update asset requirements and console behavior. Recheck the live help text for image counts, formats, pixel dimensions, and content policies rather than relying on a number in an old internal template.

If a warning appears, capture the console message and resolve that requirement directly. Do not repeatedly recompress an image when the actual problem is a device slot, graphic type, or content rule.

Separate image validation from content review

Technical validation checks pixels, format, file weight, and readability after export. Content review checks that screenshots show the current app, use accurate claims, and comply with the listing policies. Passing one review does not imply the other is complete.

Keep a reviewer checklist next to the release folder. Have one person verify the device slot and dimensions and, where possible, another check the message and product accuracy before upload.

Use a controlled replacement process

When correcting one asset, identify its device type, locale, and position before uploading the replacement. Compare the preview after processing and make sure other locales or tablet sets were not unintentionally changed.

Save the accepted file and note the console version or release date. If an issue appears later, you can reproduce the replacement without searching through older exports.