Mobile Screenshot Sizes in Pixels: A Developer’s Guide
Find the right mobile screenshot dimensions for App Store, Google Play, and in-app captures, with pixel tables, export rules, and a developer checklist.
There is no single mobile screenshot size in pixels. The correct dimensions depend on where the image will be used: an Apple App Store listing, a Google Play listing, or an in-app/device capture. Store submissions have platform rules; native captures describe a particular device, viewport, and scale.
Use this guide to choose the target platform and device class, export the right pixel dimensions, validate the file, and automate repeated captures.
1. Choose the destination before choosing pixels
| Destination | How dimensions work | What to record |
|---|---|---|
| Apple App Store | Device-class-specific screenshot specifications. Apple lists exact accepted dimensions for each class. | iPhone or iPad class, model grouping, orientation, localization, file format. |
| Google Play listing | Broad pixel bounds and aspect-ratio limits rather than one required phone resolution. | Device type, orientation, pixel dimensions, file format, transparency, listing placement. |
| In-app or device capture | Determined by the target device, viewport, browser/app scale, and capture method. | Device/model, viewport in CSS pixels, device-pixel ratio, resulting image dimensions, capture tool. |
A store upload size is a submission requirement. It is not a universal chart of the physical screen resolution of every phone. Do not use marketing-asset dimensions to describe a device’s native display.
2. Apple App Store screenshot sizes
Apple maintains a model and display-class table in App Store Connect screenshot specifications. Select the exact device grouping shown there immediately before export because requirements can change.
6.9-inch iPhone examples
For 6.9-inch iPhone portrait screenshots, Apple’s current table includes these examples:
| Orientation | Accepted example dimensions |
|---|---|
| Portrait | 1260 × 2736, 1290 × 2796, or 1320 × 2868 pixels |
| Landscape | 2736 × 1260, 2796 × 1290, or 2868 × 1320 pixels |
Landscape dimensions are the portrait width and height reversed. These are examples from Apple’s larger device-specific table, not a replacement for checking the model grouping for your app.
13-inch iPad examples
| Orientation | Accepted example dimensions |
|---|---|
| Portrait | 2064 × 2752 or 2048 × 2732 pixels |
| Landscape | 2752 × 2064 or 2732 × 2048 pixels |
Apple states that the 13-inch iPad screenshot class is required when the app runs on iPad. For iPhone apps, the 6.5-inch class is required when 6.9-inch screenshots are not provided.
Apple scaling and custom sizes
If the interface is identical across device sizes and localizations, Apple says you can provide only the highest-resolution screenshots required and they automatically scale down to smaller sizes. Use Media Manager when a device or localization needs a custom image. Scaling does not remove the need to select the correct class in App Store Connect.
Apple accepts one to 10 screenshots in JPEG, JPG, or PNG format. Read the live specification table for the current list of classes and exact dimensions.
3. Google Play screenshot sizes
Google Play does not prescribe one phone screenshot resolution for every listing. Its general asset rules are:
- JPEG or 24-bit PNG.
- No alpha channel (no transparency).
- Each image must be 320 to 3840 pixels.
- The long edge cannot be more than twice the short edge.
- At least two screenshots across different device types are required to publish a listing.
For app recommendation formats that use screenshots, Google highly recommends at least four screenshots at a minimum 1080-pixel resolution: portrait at least 1080 × 1920, or landscape at least 1920 × 1080.
| Use case | Practical dimensions | Status |
|---|---|---|
| General Play listing | Any accepted image from 320 to 3840 pixels, with a long edge no more than twice the short edge | Platform bounds |
| Recommendation placements | Portrait at least 1080 × 1920 or landscape at least 1920 × 1080 | Google recommendation |
Google says screenshots should show the actual app or game experience, be clear and correctly rotated, and not be stretched or compressed. Keep taglines limited, avoid calls to action and promotional claims, and localize additional graphic text when appropriate. Check Google Play’s preview asset guidance before submitting.
4. Device captures: CSS pixels versus image pixels
For an in-app or browser capture, first define the viewport in CSS pixels. The output image usually also depends on device-pixel ratio (DPR) or a retina scale:
output width = viewport width × capture scale
output height = viewport height × capture scale
For example, a 390 × 844 CSS-pixel viewport captured at scale 3 produces a 1170 × 2532 image. That result describes the chosen viewport and scale; it does not prove that every phone with a similar diagonal uses those dimensions.
Full-page versus viewport screenshots
- Viewport capture: records only the visible screen. Use it for a realistic above-the-fold device image.
- Full-page capture: stitches the page vertically and can include content below the fold. Use it for documentation, QA, and long web pages.
- Element capture: captures one CSS-selected element when the whole page is unnecessary.
For reproducible results, record the URL, viewport width and height, scale, orientation, browser or rendering engine, wait condition, and whether the page was full-page or element-only.
5. A repeatable export workflow
- Choose the destination. Mark the asset as Apple listing, Google Play listing, or in-app capture.
- Select the target class. On Apple, use the exact model grouping. On Google Play, choose device types and a portrait or landscape plan.
- Set orientation. Keep the app’s real orientation. Rotate dimensions only when the product itself supports that orientation.
- Capture at the intended scale. For a device capture, set the viewport and DPR/retina scale before taking the image.
- Export an accepted format. Apple accepts JPEG/JPG/PNG. Google Play requires JPEG or 24-bit PNG without alpha.
- Validate dimensions and aspect ratio. Check width, height, file type, color mode, transparency, and sharpness.
- Review content. Confirm the screen shows the real product, is correctly rotated, and contains localized text where required.
- Verify current rules. Recheck Apple’s live table or Google’s live guidance immediately before upload.
6. Automating mobile-sized captures
For a browser-based workflow, configure a mobile viewport, choose a scale, wait until the page is ready, and save the image. A production capture should also account for lazy-loaded images, cookie banners, animations, and network failures. Keep the capture configuration with the resulting file so another developer can reproduce it.
Useful capture controls
- Preset mobile devices or a custom viewport.
- Portrait or landscape orientation.
- Retina/device scale.
- Full-page or CSS-element capture.
- Dark mode and transparent background when the destination permits them.
- Custom CSS or JavaScript to put the page in a known state.
- Clicking an element before capture.
- Waiting for a selector, a delay, or network idle.
- Hiding selectors and blocking ads, trackers, requests, or resource types.
- Custom headers, cookies, user agent, Authorization, timezone, and geolocation.
- Image resizing and a chosen cache TTL for repeated captures.
7. Or skip the browser setup
ScreenshotNeo is a website screenshot API and MCP server. One GET request returns a PNG, JPEG, WebP, or PDF, and its viewport/device, full-page, element, scale, waiting, CSS/JavaScript, blocking, headers, cookies, timezone, geolocation, resizing, caching, async, bulk, and PDF controls cover common mobile capture workflows. See the ScreenshotNeo API documentation for the current request options.
cURL
curl -G "https://api.screenshotneo.com/v1/shot" -d access_key=YOUR_API_KEY --data-urlencode url=https://stripe.com -o shot.webp
Python
import requests
r = requests.get(
"https://api.screenshotneo.com/v1/shot",
params={"access_key": "YOUR_API_KEY", "url": "https://stripe.com"},
timeout=90,
)
r.raise_for_status()
open("shot.webp", "wb").write(r.content)
Node.js
const q = new URLSearchParams({ access_key: 'YOUR_API_KEY', url: 'https://stripe.com' });
const res = await fetch(`https://api.screenshotneo.com/v1/shot?${q}`);
if (!res.ok) throw new Error(`HTTP ${res.status}`);
const image = Buffer.from(await res.arrayBuffer());
require('fs').writeFileSync('shot.webp', image);
ScreenshotNeo removes cookie and consent banners, newsletter popups, and chat widgets before the capture. Bot checks, blank pages, timeouts, failed loads, and cache hits are not billed; the response identifies the result with X-Page-Verdict and X-Billed headers. Its MCP server provides take_screenshot, get_page_info, and capture_pdf tools for Claude, Cursor, and other MCP clients.
Free usage includes 1,000 screenshots per month without a card. Paid plans start at $5 for 3,000 shots; yearly billing gives two months free, and every feature is available on every plan. Create a free ScreenshotNeo account.
8. Troubleshooting
| Symptom | Likely cause | Fix |
|---|---|---|
| Apple rejects the image size | Wrong device class or a dimension copied from another model group. | Return to Apple’s current table, select the exact class, and export its listed portrait or landscape dimensions. |
| Google Play rejects the file | Alpha channel, unsupported format, dimensions outside 320–3840 pixels, or an aspect ratio over 2:1. | Export JPEG or 24-bit PNG without alpha and validate both edges and the long-edge ratio. |
| Image looks stretched | Artwork was resized without preserving its aspect ratio or the wrong orientation was selected. | Capture at the target viewport and scale, then resize proportionally only when required. |
| Screenshot is blurry | Captured at a low scale and enlarged later. | Capture at the intended device scale or a higher source resolution; avoid upscaling as the final step. |
| Bottom content is missing | A viewport capture was used for a page that needs full-page output. | Use full-page capture, or capture the specific element that contains the required content. |
| Page contains a consent banner or chat bubble | The page was captured before the UI was dismissed. | Accept or remove the banner in the workflow, hide the selector, or use ScreenshotNeo’s cleanup before capture. |
| Lazy images are blank | The capture occurred before scrolling or the images finished loading. | Wait for a selector or network idle, add a delay, or use a full-page workflow that loads lazy content. |
| Authenticated content is missing | Cookies, headers, or Authorization were not supplied. | Provide the required session data through the capture tool and avoid storing secrets in public URLs. |
| Automated result varies between runs | Animations, changing data, ads, geolocation, or timing differences. | Freeze animation with custom CSS, block irrelevant requests, set timezone/geolocation, and use a deterministic wait condition. |
9. Performance, reliability, and cost notes
- Performance: Full-page captures and high retina scales produce larger images and take longer than viewport or element captures. Block unnecessary ads, trackers, and resource types when they are not part of the screen you need.
- Reliability: Wait for a selector or network idle instead of relying only on a fixed short delay. Keep the viewport, scale, orientation, and content state fixed across runs.
- Caching: Use a cache TTL for unchanged URLs when repeat requests do not need a fresh render. A cache hit is not billed by ScreenshotNeo.
- Batch work: ScreenshotNeo supports bulk capture for up to 100 URLs per call and asynchronous jobs with signed webhooks for larger pipelines.
- Cost control: Failed loads, bot checks, blank pages, timeouts, and cache hits are not billed by ScreenshotNeo. The usage API and
X-Billedresponse header help reconcile requests with billable clean shots. - Security: Keep API keys server-side. Use signed links for public
<img>tags and pass private headers or cookies only from a trusted backend.
10. Final submission checklist
- Destination identified: Apple, Google Play, or in-app capture.
- Exact device class or device type selected.
- Portrait or landscape matches the product experience.
- Width and height checked in pixels.
- Apple file is JPEG/JPG/PNG; Google file is JPEG or 24-bit PNG with no alpha.
- Google image is between 320 and 3840 pixels and within the 2:1 long-edge limit.
- At least two Google Play screenshots cover different device types.
- Recommendation assets meet Google’s 1080-pixel guidance when applicable.
- No stretching, compression artifacts, accidental overlays, or untranslated graphic text.
- Current Apple or Google documentation reviewed immediately before upload.
FAQ
Is 1080 × 1920 the standard mobile screenshot size?
It is a Google recommendation for portrait screenshots in certain recommendation placements, not a universal mobile or App Store size.
Should I export screenshots at a phone’s physical resolution?
For a store listing, follow that store’s asset specification. For an in-app capture, document the target viewport and scale and export the resulting image dimensions.
Can one Apple screenshot cover every iPhone?
Apple can scale the highest required resolution down when the interface is the same, but you must still follow the current device-class rules and provide custom sizes when needed.
How many Google Play screenshots are required?
Google requires at least two screenshots across different device types to publish a listing. Additional recommendation formats may call for at least four high-resolution images.
Which format is safest for Google Play?
Use JPEG or 24-bit PNG without an alpha channel, then verify the current Play Console guidance before upload.


