1. Check your listing images
Drop your screenshots and icon here
or
Files named like AppIcon.png, ic_launcher-playstore.png or feature-graphic.png are recognised as an icon or feature graphic; everything else is treated as a screenshot.
2. Files read
| File | Treated as | Format | Size |
|---|
Findings
Prefer a CLI, or want this as a release gate?
The CLI runs the same checks over a directory of assets and exits non-zero when something would block the upload — so a wrong-size screenshot fails the build instead of the release:
node check.mjs ./fastlane/screenshots/en-US node check.mjs --store play ./play/listing node check.mjs ./screenshots --json node check.mjs ./screenshots --strict # notices fail too
Get check.mjs, engine.mjs, image.mjs and spec.mjs from the repo — plain Node 18+, nothing to install. It opens no sockets and writes nothing: it reads the header bytes of the files you name and prints a report. Exit code 1 when a danger-severity finding is produced, 2 when the arguments or paths could not be used.
What's checked
| Check | What it flags | Severity |
|---|---|---|
| Icon transparency | An App Store icon with an alpha channel or a tRNS chunk | Danger |
| Icon dimensions | An icon that is not exactly the size the store requires | Danger |
| File format | A file whose real bytes are HEIC, WebP, GIF or similar — whatever it is named | Danger |
| Set consistency | Screenshots in one set that disagree about their pixel dimensions | Danger |
| Screenshot count | More screenshots than the store accepts per set | Danger |
| Play bounds | A side outside 320–3840px, or an aspect ratio past 2:1 | Danger |
| Feature graphic | A Play feature graphic that is not exactly 1024×500, or is transparent | Danger |
| Mixed orientation | Portrait and landscape images in the same set | Notice |
| Unrecognised size | A screenshot matching no display class in this tool's table | Notice |
| Icon encoding | An interlaced PNG, or one deeper than 8 bits per channel | Notice |
More: why store uploads get rejected, and the four mistakes that cause most of it. See also: how this differs from checking the spec sheet by hand.
Common questions
Why does App Store Connect reject an app icon for transparency?
Apple requires the App Store icon to be fully opaque, and the check happens at upload time — after the build and the archive, at the most expensive point in a release to discover it. A PNG declares transparency in two ways: its IHDR colour type can include an alpha channel (types 4 and 6), or a tRNS chunk can make specific colours transparent in an image that has no alpha channel at all. Both count. The fix is to flatten the icon onto an opaque background and re-export; exporting as JPEG also works, since JPEG has no alpha channel. Do not draw the rounded corners yourself — the store masks them for you, and a pre-masked icon is what usually leaves transparent corners behind.
Why does this read the file's bytes instead of its extension?
Because the extension is usually the thing that lied. Renaming a HEIC screenshot from an iPhone, or a WebP from an Android device, to .png does not convert it — the bytes stay HEIC or WebP, and the store reads the bytes. A checker that trusts the filename passes exactly the file that is about to be rejected. This tool identifies each file from its magic bytes, so a misnamed file is reported as what it actually is.
What does it mean that a screenshot set is inconsistent?
A set of screenshots uploaded for one display class has to agree with itself about its pixel dimensions. The ordinary way a set breaks is that some of it was regenerated on a newer simulator or a different device and the rest was kept — the files look fine individually and the mismatch is invisible in a file listing. This check needs no specification at all: it compares the files with each other, so it cannot go out of date when a store changes its size tables.
Are the size tables in this tool authoritative?
No, and it is built to say so. The checks split in two. Structural checks — is this really a PNG, does this icon declare transparency, do these screenshots agree with each other — are answered from the files themselves and cannot go stale. Table checks compare against a transcription of each store's published sizes, and Apple and Google add and retire device classes, so a size this tool does not recognise is reported as a notice that names the table as the thing that might be wrong, never as a failure. Each store's own current documentation is authoritative.
Is anything uploaded when I drop images on this page?
No. The files are read in your browser with the File API and only the first few dozen header bytes of each are examined — no pixels are decoded, no image is transmitted, and no filename, dimension or result is recorded anywhere. Your unreleased app's artwork stays on your machine. The page keeps only an anonymous local count of how many times the check button was pressed, which you can switch off below.