Updated: July 26, 2026
To compress app store screenshots, keep the original export, run lossless PNG optimization first, and use lossy compression only when the result still needs to be smaller and the output remains compatible with the target platform. Export Apple and Google Play assets separately at accepted dimensions. Google Play currently specifies JPEG or 24-bit PNG with no alpha channel, while Apple accepts PNG or JPEG at listed device dimensions and does not allow transparency. Before uploading, verify pixel dimensions, actual file format and PNG color type, alpha channel status, text edges, gradients, and the current requirements shown in App Store Connect or Google Play Console.
Key Takeaways
- Export Apple and Google Play screenshots separately — accepted dimensions and aspect ratio rules differ between platforms.
- Google Play requires JPEG or 24-bit PNG with no alpha. An 8-bit indexed PNG from pngquant does not meet this requirement.
- Apple accepts PNG and JPEG at listed device dimensions. Check the current Apple screenshot specifications for the full list of accepted sizes.
- Run lossless optimization (oxipng, ImageOptim) first. Apply lossy compression only if the file still needs to be smaller, and only if the output format remains compatible with the target platform.
- Verify pixel dimensions, actual PNG color type, alpha channel, text edges, and gradients on every output before uploading.
- Neither store currently accepts WebP or AVIF for screenshots.
Why Compression Quality Matters on App Product Pages
App store product pages are a conversion surface, not just an upload checkpoint. Every screenshot competes at thumbnail size in search results, at larger sizes on the product page itself, and across device sizes. A screenshot with visible banding, blurry text, or compression artifacts around UI elements can undermine trust before a user reads the first word.
The compression goal is narrow: reduce file size enough to comply with current upload limits and keep processing fast, without introducing any degradation visible at the sizes stores actually display your screenshots. That is a different problem from generic web image optimization. Screenshots typically contain UI text and flat color blocks that are sensitive to palette quantization and JPEG compression — formats and quality settings that work well for photographs can visibly degrade app UI screenshots.
Check Current App Store and Google Play Screenshot Requirements
Always verify requirements in the current platform console before uploading. The table below reflects publicly documented rules as of July 2026; requirements can change without notice.
Apple App Store Connect (iOS)
| Requirement | Current Rule |
|---|---|
| Accepted formats | PNG (.png), JPEG (.jpeg, .jpg) |
| Transparency / alpha | Not allowed |
| Color space | Check current App Store Connect documentation |
| Accepted phone sizes (6.9″ display) | 1260×2736, 1290×2796, 1320×2868 px portrait (among others) |
| Accepted iPad sizes (13″ display) | 2064×2752, 2048×2732 px portrait (among others) |
| Screenshots per device class | 1–10 |
| Authoritative source | Apple Developer – Screenshot Specifications |
Apple lists multiple accepted dimensions for each display size. Do not assume a single pixel size is the only valid option. When the accepted dimensions for your target device are not matched exactly, the upload will be rejected. Check the current App Store Connect specification page for the full list before exporting.
If you submit screenshots for only the highest supported iPhone display class, Apple may scale them down for smaller displays where the UI layout is the same. Verify this behavior in the current documentation for your app's configuration.
Google Play Console (Android)
| Requirement | Current Rule |
|---|---|
| Accepted formats | JPEG, 24-bit PNG (no alpha) |
| Transparency / alpha | Not allowed |
| Dimensions (per side) | 320 px minimum, 3840 px maximum |
| Aspect ratio | Long side must not exceed 2× the short side |
| Recommended portrait size | 1080×1920 px (required for some featured placements) |
| Minimum to publish | At least 2 screenshots across supported device types |
| Maximum per device type | 8 |
| Feature Graphic (separate asset) | 1024×500 px, JPEG or 24-bit PNG |
| Authoritative source | Google Play – Store listing: screenshots |
The 1080×1920 recommendation is tied to eligibility for certain featured placements, not the minimum to publish. The minimum to publish is two screenshots across supported device types. Each supported device type allows up to eight screenshots.
iPhone portrait screenshots at tall aspect ratios (where the long side exceeds twice the short side) fall outside Google Play's accepted ratio range. Do not reuse or crop the same file — re-compose at accepted Google Play dimensions.
Apple vs. Google Play: Compression Compatibility
The most important difference for compression is PNG color type:
- Google Play requires 24-bit PNG (truecolor, no alpha). Tools like pngquant convert truecolor PNG to indexed (8-bit palette) PNG, which is a different PNG color type. An indexed PNG does not meet Google Play's 24-bit PNG requirement even if the file extension is
.png. - Apple accepts PNG without specifying a color type in its current public documentation. However, no transparency is allowed.
Why an Indexed PNG May Not Meet Google Play's 24-Bit Requirement
When pngquant compresses a PNG, it reduces a 24-bit truecolor image (millions of possible colors) to an indexed palette of up to 256 colors. The resulting file has PNG color type 3 (indexed-color), not color type 2 (truecolor) or color type 6 (truecolor with alpha).
Google Play's current documentation specifies "24-bit PNG" — which corresponds to color type 2 or color type 6 without the alpha component. An indexed PNG from pngquant does not meet this specification.
For Google Play screenshots:
- Use JPEG (no alpha issue, widely accepted), or
- Use a lossless optimization tool (oxipng, ImageOptim) that keeps the PNG as 24-bit truecolor.
- If you want to apply any palette-based lossy compression for Google Play, verify that the actual uploaded file is accepted by uploading to the console and checking for rejection.
For Apple screenshots:
- Both PNG and JPEG are accepted formats.
- No transparency is allowed regardless of format.
Lossless PNG, Lossy PNG, or JPEG: Which Should You Use?
| Method | Tools | Typical effect | Visible quality loss | Platform compatibility |
|---|---|---|---|---|
| Lossless PNG optimization | oxipng, ImageOptim, OptiPNG | Removes metadata and re-encodes; savings depend on image content | None (pixels unchanged) | Apple: yes. Google Play: yes (remains 24-bit PNG) |
| Lossy PNG (palette quantization) | pngquant, TinyPNG | Converts to indexed PNG; savings depend on image content | Can be minimal at high quality settings, visible at low settings | Apple: check actual upload result. Google Play: does not meet 24-bit PNG requirement |
| JPEG | Any encoder | Depends on quality setting and image content | Yes, especially around text edges | Apple: yes. Google Play: yes |
| WebP / AVIF | Various | — | — | Not listed as accepted formats on either platform |
The practical decision:
- Lossless first. Run oxipng or ImageOptim on every screenshot before considering anything else. For flat UI screenshots with text and solid colors, lossless optimization often produces files that comfortably meet upload limits.
- JPEG for Google Play if PNG is still large. If a lossless PNG for Google Play is still large, JPEG is the safest lossy alternative — it stays truecolor, is accepted by Google Play, and avoids the indexed PNG compatibility issue.
- For Apple, pngquant is an option if you verify the result. Apple accepts PNG without specifying color type in its current public documentation. If you use pngquant for Apple screenshots, visually verify the output and test an actual upload.
A Safe Screenshot Compression Workflow
This workflow keeps your master files intact. All compressed output goes to a separate directory.
Step 1: Export at accepted dimensions with no alpha
Export from Figma, Sketch, or your screenshot tool at one of the accepted dimensions for each target platform. Confirm:
- The color mode is set according to your design tool's export settings for standard screen content.
- There is no transparency or alpha channel. Flatten all transparent layers onto an opaque background before exporting.
- Save the master files in a dedicated directory (for example,
masters/). Do not modify these files during the compression workflow.
Step 2: Run lossless optimization on all screenshots
Create an output directory before running any tools:
mkdir -p optimized/
Mac (GUI): Drop files into ImageOptim. It applies multiple lossless optimization passes and removes metadata by default. Save copies to your output directory.
Command line with oxipng:
oxipng -o 3 --strip safe --out optimized/ masters/*.png
-o 3 balances speed and compression (the scale goes from 0 to 6). --strip safe removes metadata that is not needed by renderers. --out optimized/ writes results to the output directory without touching the originals.
Oxipng documentation confirms that lossless optimization leaves pixels unchanged. The resulting PNG remains 24-bit truecolor, which is compatible with both Apple and Google Play PNG requirements.
Step 3: Apply lossy compression if needed — only for Apple, with visual verification
If a screenshot intended for Apple is still large after lossless optimization and you want to apply lossy compression:
pngquant --quality=75-90 --output optimized/compressed.png -- masters/original.png
The --quality range tells pngquant to produce output only if it can maintain a visual quality score within that range; otherwise it exits with a non-zero status code (99) without producing output. This protects against silently shipping a degraded image.
Note that pngquant produces indexed (8-bit palette) PNG. This is appropriate for Apple screenshots if the visual result is acceptable, but it does not produce a 24-bit PNG suitable for Google Play.
For Google Play, use JPEG instead:
ffmpeg -i masters/original.png -q:v 2 optimized/play_screenshot.jpg
Or use your design tool to export directly as JPEG. If using ImageOptim, it can also apply JPEG compression.
Step 4: Re-run lossless optimization on quantized files
If you used pngquant, run oxipng again on the output to further reduce file size:
oxipng -o 3 --strip safe optimized/compressed.png
pngquant's initial output is not losslessly minimized; a second pass can reduce the file further. Skip this step for JPEG files.
Step 5: Safe batch workflow
For a release with multiple screenshots, use this pattern that separates inputs from outputs and handles compression failures:
#!/usr/bin/env bash
set -euo pipefail
MASTERS="masters"
OPTIMIZED="optimized"
mkdir -p "$OPTIMIZED"
# Lossless pass: copy all PNGs to optimized/ first, then optimize in place
for f in "$MASTERS"/*.png; do
name="$(basename "$f")"
cp "$f" "$OPTIMIZED/$name"
oxipng -o 3 --strip safe "$OPTIMIZED/$name"
done
echo "Lossless pass complete. Review $OPTIMIZED/ before applying lossy compression."
echo "For Apple only: apply pngquant to individual files that remain large."
echo "For Google Play: use JPEG or keep 24-bit PNG — do not use pngquant output."
This script never modifies files in the masters/ directory.
Browser Workflow with LessMB
If you prefer a no-install browser workflow, LessMB compresses images locally on your device and lets you adjust quality or output dimensions before downloading the result. Use it for the compression step on individual screenshots, then verify each exported file against Apple's or Google Play's current format, bit depth, alpha, and pixel dimension requirements before uploading to the console.
Final Verification Checklist
Both consoles can reject uploads without detailed error messages. Check every final file before uploading.
Verify Format, PNG Color Type, and Alpha
| Check | How to verify | Expected result |
|---|---|---|
| Pixel dimensions | sips -g pixelWidth -g pixelHeight file.png on macOS | Must match one of the accepted sizes for that platform |
| File format | file file.png or check extension | PNG or JPEG as required by platform |
| PNG color type | pngcheck -v file.png or identify -verbose file.png (ImageMagick) | Color type 2 (truecolor) for Google Play; indexed (type 3) not accepted |
| Alpha channel | identify -verbose file.png | grep Alpha | No alpha for either platform |
| File size | ls -lh file.png | Under the current upload limit shown in the console |
| Output directory | Confirm file is in optimized/, not masters/ | Source files must remain unchanged |
Compare Text and Gradients at Full Size and Thumbnail Size
After compression, open the output file at 100% zoom and check:
- Text edges: no visible fringing, halos, or blurring compared to the master.
- Gradients and background areas: no visible banding or color stepping.
- Flat color blocks: colors match the master without unexpected shifts.
Also check the image at a reduced size similar to how it will appear in search results. Artifacts that are subtle at full size can become more noticeable at smaller sizes where edges and transitions are compressed into fewer pixels.
Common Compression and Upload Mistakes
- Using pngquant output for Google Play. pngquant produces indexed (8-bit) PNG, which does not meet Google Play's 24-bit PNG requirement. Use JPEG or lossless 24-bit PNG for Google Play.
- Re-saving an existing JPEG as JPEG. If your source is already JPEG, re-exporting at a lower quality compounds artifact damage. Re-export the original design as PNG, then optimize.
- Overwriting master files. Run all compression with separate input and output directories. Never apply
--force --outputor in-place optimization to your original exported masters. - Assuming one set of screenshots works for both stores. Apple and Google Play have different accepted dimensions and aspect ratio constraints. Re-compose at the accepted size for each platform.
- Skipping the PNG color type check for Google Play. A file named
.pngcan be indexed or truecolor. Verify the actual color type, not just the extension. - Forgetting iPad if your app supports it. Apple requires a separate screenshot set for iPad when your app supports iPad. Check the current App Store Connect documentation for which device classes require separate assets.
- Not checking current requirements. Platform requirements change. Always verify dimensions, formats, and any other constraints in the current App Store Connect or Google Play Console documentation before a release.
References
- Apple Developer – Screenshot Specifications: developer.apple.com/help/app-store-connect/reference/app-information/screenshot-specifications/
- Google Play – Store listing, screenshots and graphics: support.google.com/googleplay/android-developer/answer/9866151
- pngquant – lossy PNG compressor: pngquant.org
- oxipng – multithreaded PNG optimizer: github.com/oxipng/oxipng
- ImageOptim – better Save for Web for Mac: imageoptim.com/mac
- TinyPNG – compress PNG and JPEG images: tinypng.com (check current free-tier limits on the site)
- LessMB – local browser image compression: lessmb.com
FAQ
Does pngquant output meet Google Play's 24-bit PNG requirement?
No. pngquant converts truecolor PNG to indexed (8-bit palette) PNG — PNG color type 3. Google Play requires JPEG or 24-bit PNG (color type 2, no alpha). An indexed PNG does not meet this requirement, regardless of file extension. For Google Play, prefer JPEG or optimize your PNG with a lossless tool like oxipng that preserves the 24-bit truecolor color type. If you are unsure, verify the PNG color type with pngcheck -v file.png or identify -verbose file.png before uploading.
Is PNG or JPEG better for app store screenshots?
It depends on the image content and the target platform. PNG is generally safer for screenshots that contain UI text and flat or solid colors because the lossless format keeps edges sharp. JPEG can produce smaller files for screenshots with photographic backgrounds but introduces artifacts around text. Apple accepts both PNG and JPEG. Google Play accepts JPEG and 24-bit PNG with no alpha. If you use JPEG, start with a high quality setting and check text edges before finalizing. Verify the current accepted formats in each platform's console.
Does compression affect App Store or Google Play submission?
The technical compression format can affect whether a file passes or fails the upload format check. A file must meet the current accepted format, pixel dimensions, and alpha restrictions for the target platform, regardless of how it was compressed. Visual quality from aggressive compression is not directly checked in the upload process, but degraded screenshots can affect user perception and conversion. Always verify the output file against current platform requirements and do a visual review before uploading.
Do I need separate screenshots for iPhone and Android?
Yes. Apple and Google Play have different accepted sizes and aspect ratio constraints. Tall iPhone portrait dimensions — where the long side is more than twice the short side — fall outside Google Play's accepted ratio range. Re-compose your screenshots at each platform's accepted dimensions rather than cropping or scaling the same file.
What DPI should app screenshots use?
Both Apple and Google Play specify requirements in pixels, not DPI. The pixel dimensions are what matter. DPI metadata in the file does not substitute for correct pixel dimensions; validate pixel size, not DPI.
Can I use WebP or AVIF for app store screenshots?
No. Neither Apple App Store Connect nor Google Play Console lists WebP or AVIF as accepted screenshot formats. Use PNG or JPEG. WebP is suitable for web delivery, not store listings.
Should I compress screenshots before or after localization?
After localization. Finalize the design for each locale, export all locale masters at accepted dimensions for each platform, then run the same compression workflow on the complete set. Compression decisions are format and content dependent, not language dependent.
How do I batch-compress screenshots without overwriting my originals?
Always use separate input and output directories. Keep your exported masters in a directory like masters/ and write all compressed files to a different directory like optimized/. Never pass the same path as both input and output to oxipng or pngquant. The batch script in this article demonstrates this pattern. Check the exit code of each compression tool before treating the output as ready to upload.