Google Play Screenshot Rejected for Transparency? How to Diagnose and Re-Export

You upload screenshots to Play Console, the progress bar finishes, and then a message pops up about "transparency", "alpha" or "PNG bit depth". It comes up regularly in indie developer groups. Feature review hasn't even started, and you're already stuck on assets.

Google's requirements for phone screenshots are actually very direct: use JPEG or 24-bit PNG, and no alpha transparency channel. The app icon, on the other hand, may be a 512×512 32-bit PNG with transparency. Many people mix up the two rules: they export from Figma, Sketch or a background remover with a transparent background, and the store preview images are rejected while the icon passes fine.

First, confirm which field the error is in

Open Play Console → Main store listing (or the relevant custom store listing) → Phone screenshots. If the error appears in this field, it's about the store preview images, not the app icon and not the 1024×500 Feature Graphic. The Feature Graphic also must have no transparency; the icon is the exception.

Drag the suspect file onto your desktop preview: if you see a checkerboard or the wallpaper shows through, it almost certainly has alpha. The system "Details" panel sometimes shows 32-bit. You can also open it in this site's image format converter, save it again, and see whether the transparency is still there.

For broader rules on layout, number of screenshots and first-screenshot strategy, see the Google Play screenshot design guide 2026. This article deals only with transparency.

Where the transparency usually comes from

Three sources are the most common.

Design tool artboards are transparent by default and export PNGs with alpha. An interface with "hollow" edges sits on top of the Play listing background with colors bleeding through, and Google rejects it outright.

Reusing files from your iOS workflow. The App Store is less sensitive than Play about whether PNGs contain transparency, so the same image with transparent edges may pass in App Store Connect and fail on Play.

Uploading a background-removal result as the final asset. This site's online solid background remover outputs a transparent PNG; that's what it's for. It's good as a layer asset, not as a Play phone screenshot as-is. To publish, put a solid background behind it first, or save it as JPG.

Recommended: re-export a version without transparency in the editor

Open the Google Play screenshot generator, or go straight to the screenshot editor at /preview. Use Play's common portrait size, 1080×1920, for the canvas (explained on the generator landing page). Choose a solid color or gradient background that fills the whole canvas, with no transparent gaps around the edges.

Paste in your app interface and add a short line of copy if needed. You can preview up to 10 screenshots at a time, and "Export all" gives you a zip (containing PNGs named by size preset and sequence number). Play-related export paths fill the background solidly to avoid alpha holes; after unzipping, you should see opaque PNGs.

If you still want extra certainty, convert the files in the zip to JPG with the image format converter. JPEG has no transparency channel, Play accepts it, and it causes the least trouble. If files are too large, use image compression to get under the limit shown in Console. Documentation commonly mentions around 8MB per image; go by the current red warning text in your account.

The 1024×500 Feature Graphic can't be transparent either. You can make one with a custom canvas in the editor, or finish it and then use image crop and resize to get exact pixels.

If you also maintain 6.9-inch App Store screenshots (1320×2868), keep the two sets in separate folders so you don't accidentally upload iOS PNGs with transparent decorations to Play. For the iPhone set, see the 6.9-inch screenshot size tutorial.

If you don't want to redo the layout: add a background or convert to JPG

If the layout is final and only the channel is wrong, take the short path:

1. Confirm the file has transparency.
2. Convert to JPG, or add a white or brand-color layer under the original design and export a 24-bit PNG.
3. In Console, delete the old screenshots first, then upload the new files, and do a hard refresh. Just "overwriting" an upload sometimes still reads the cache, making it look as if the fix didn't work.

Note: many "PNG compression" tools only reduce file size and don't remove alpha. After compressing, you'll still get the transparency error. The goal is removing the channel, not just making the file smaller.

Apple rejections more often involve real UI and misleading marketing; transparency is rarely the main cause there. You can compare strategies on both sides in screenshot rejections and ASO, but fix files separately per platform.

A two-minute check after uploading

In Console, open the phone preview of your store listing and swipe through. If you see odd color blocks or ragged see-through edges, the channel or scaling is probably still wrong; try JPG instead.

If the same set also goes to Huawei, Xiaomi, OPPO, vivo and Tencent MyApp (应用宝), sizes and counts are often around 1080×1920, but file size limits vary. It's safer to re-export according to China app store screenshot sizes rather than assuming "if it passed Play, it'll pass in China". (For overseas developers: Android apps in mainland China are distributed mainly through these phone-maker and platform stores rather than Google Play.)

Keywords, the short description and ASO structure are the next stage; once your format passes, you can continue with the 2026 Google Play ASO guide.

Checking the channel quickly with system tools (optional)

On macOS, open the PNG in Preview and choose Tools → Show Inspector → More Info → PNG; some system versions list Alpha. On Windows, a free image viewer can show bit depth. If you're unsure, the simplest signal is still whether there's a checkerboard.

If you're comfortable with the command line, file or ImageMagick's identify can show whether there's alpha. If you don't have those tools, converting to JPG and re-uploading is a perfectly practical fallback.

Don't confuse it with "file too large" errors

Console sometimes throws two errors in a row: first transparency, then, after you fix that, a size error. Transparency is a channel problem and oversize is a file size problem; handle them separately. First make sure there's no alpha (or switch to JPG), then reduce size with image compression. Do them in the wrong order and you may keep uploading "blurry, compressed transparent PNGs", with the two errors bouncing back and forth and half a day wasted.

There's also a rarer case: you uploaded an animated WebP or an odd encoding with an ICC profile. Google allows WebP, but the simpler your asset pipeline, the better. If you've already been rejected for transparency, I'd suggest choosing only between JPG and non-transparent PNG for this round, and trying WebP once things are stable.

Multiple language store listings

If the same app has several store listings, such as English and Japanese, screenshots are stored per listing. Fixing transparency in the default language may leave old files in other language sections. If the rejection email mentions a particular language code, check the corresponding listing rather than only the Chinese one.

The order I actually troubleshoot in

After a rejection email or red error text, I usually do just four steps, to avoid changing size, copy and format at once and muddling the problem.

Step one: download the current image from Console and confirm locally whether it has transparency. Step two: change only the format or only add a background, leaving all other pixels alone. Step three: delete the old file and upload the new one. Step four: check the phone preview; if there's no more error, stop. If the preview looks fine but you still get an old email, wait a few hours or check the email timestamp; sometimes it's a queue delay.

Don't use the same change to also switch 1080×1920 to another ratio "while optimizing the first screenshot". Keep the transparency issue and its fix scoped tightly, or you won't be able to tell which change worked.

FAQ

Q: The docs say WebP is allowed. Can I use it? A: Yes, but the transparency rule applies too. For a batch already rejected for transparency, prefer JPG or non-transparent PNG and avoid fighting encoder quirks.

Q: The icon also got an error related to transparency? A: First check which field it is. The icon should be a 32-bit PNG that may include transparency, with a file size limit (commonly ≤1024KB). Don't share one export preset between the icon and phone screenshots.

Q: The zip from this site already contains opaque PNGs, but Console still shows the old error? A: Delete the old assets and re-upload, switch browsers or clear the cache. Make sure you're editing the store listing for the right language or country.

Q: Play wants 8 screenshots. Is one editor session enough? A: Yes, a project holds up to 10. Phone screenshots need at least 2; the maximum is whatever Console currently shows.

Once transparency is sorted, if you're still weighing competitors' first screenshots and copy density, go back to the design guide for comparison; the file format hurdle is done.