iPad Screenshot Sizes for the App Store: 13-inch, 12.9-inch and 11-inch Dimensions

iPad screenshots are the part of an App Store listing that developers most often get wrong. iPhone sizes get all the attention, so the iPad set tends to be an afterthought: someone exports a few images from the simulator, uploads them the night before release, and then App Store Connect refuses them with a vague dimensions error. This guide lists every iPad screenshot size Apple publishes, explains which ones you actually have to provide, and walks through a clean, repeatable way to produce them without sending your unreleased interface to a third-party website.

The short answer: what size are iPad App Store screenshots?

Apple lists several iPad display classes. The one that matters most is the 13-inch class. If your app runs on iPad at all, you must provide at least one screenshot at this size. The accepted portrait dimensions are 2064 × 2752 pixels and 2048 × 2732 pixels. For landscape you swap the two numbers, giving 2752 × 2064 and 2732 × 2048.

Everything else is optional in the sense that App Store Connect will scale the largest set you provide down to smaller iPad models. You only need to upload separate sets for the 11-inch or 10.5-inch classes if you want to control exactly how the screenshot looks on those devices, for example because a layout changes meaningfully at that size.

Complete iPad screenshot size table

The table below lists the iPad display classes in Apple's current specification, with portrait pixel dimensions. Landscape is always the same pair of numbers reversed.

Notice that 2048 × 2732 appears in both the 13-inch and 12.9-inch rows. That is intentional in Apple's table: the same pixel size serves both display classes, which is why a single 2048 × 2732 set is a common choice for teams that have been shipping iPad apps for years.

Do I need iPad screenshots at all?

Only if your app runs on iPad. In App Store Connect the device families your build supports determine which screenshot sections appear. An iPhone-only build does not show an iPad section, and you cannot upload iPad screenshots for it. A universal build, or an iPad-compatible build that runs in a compatibility window, behaves differently: if the binary is flagged as supporting iPad, App Store Connect expects the 13-inch set before you can submit for review.

This catches teams out when they enable the iPad destination in Xcode for convenience, for instance to test on a larger simulator, and then forget that it changes the submission requirements. If you do not intend to support iPad properly, remove the destination from the target rather than uploading placeholder screenshots. Reviewers compare screenshots with the actual experience, and stretched phone layouts on a tablet are a common cause of rejection under the guideline that screenshots must show the app in use.

How scaling works between iPad sizes

App Store Connect treats your largest iPad set as the master and scales it down for other iPad models when you do not provide a dedicated set. Scaling preserves aspect ratio within a display class family, so the 13-inch and 12.9-inch classes, which share a 3:4-ish aspect ratio, scale cleanly. The 11-inch class has a slightly different aspect ratio. In practice the difference is small, but if your design has edge-aligned UI such as a tab bar pinned to the bottom, check how the scaled version looks. If it looks wrong, provide a dedicated 11-inch set.

• Provide one 13-inch set first. It is the only mandatory iPad class.
• Preview the scaled result on the App Store product page preview in App Store Connect before you submit.
• Add an 11-inch set only if you see cropping or awkward spacing.
• Keep the same screenshot order and captions across sets so localized listings stay consistent.

Format, color and content rules

Pixel size is only one of the checks. Apple also validates the file itself, and a screenshot that has exactly the right dimensions can still be rejected for format reasons.

• Accepted file types are PNG and JPEG. PNG is the safer choice for interface screenshots because it is lossless, so text stays crisp.
• Do not include transparency. A PNG with an alpha channel can trigger a validation error or render with an unexpected black background. Flatten the image onto a solid color before export.
• Each device class and localization accepts between one and ten screenshots.
• The image must show the app in use. Splash screens and login screens alone are a frequent reason for rejection.
• Do not wrap the screenshot in a device frame unless the frame is part of marketing artwork that still shows real interface. Framed device mockups are allowed, but the output must still match the exact pixel size of the class.

Three ways to produce iPad screenshots

1. Capture from the simulator

The most reliable source of correctly sized iPad screenshots is the Xcode simulator. Choose a 13-inch iPad simulator, run your app, and use the screenshot command. The saved file has the exact native pixel dimensions of that device, which for current 13-inch iPads match one of the two accepted 13-inch sizes. This approach also guarantees that the status bar and rendering are authentic.

The downside is that the simulator shows real data states. You will usually want to seed demo content, hide personal information, and set a clean status bar time before capturing. Teams that ship often automate this with UI tests that launch the app in a fixed state and capture a screenshot at each step.

2. Export from a design file

Many teams build marketing screenshots in Figma or Sketch, with a headline above a device frame. The frame size in the design file is rarely the exact required pixel size, so you export at a scale factor and then fix it up. Exporting at 2× from a 1024 × 1366 frame yields 2048 × 2732, which is exactly the 12.9-inch and 13-inch size, so designing at 1024 × 1366 is a convenient trick. Check the export dimensions every time because a stray pixel of stroke or shadow can make the frame one pixel larger.

3. Resize existing screenshots

Sometimes you inherit screenshots of the wrong size, or you need an 11-inch version from a 13-inch master. In that case you crop and resize. The two choices are crop to fill, which scales the image until it covers the frame and trims the overflow, and pad, which keeps the whole image and fills the remaining space with a background color. For interface screenshots with edge-aligned bars, padding is usually safer because cropping can cut off navigation. For marketing artwork with generous margins, cropping looks cleaner.

Resize iPad screenshots without uploading them

Pre-release interface is confidential by default. Most online image resizers upload your file to a server, process it, and send it back, which means an unreleased feature screen sits on someone else's infrastructure, even if only briefly. For a lot of teams that is a policy violation they never noticed, and for freelancers working under an NDA it can be a contractual one.

The free TinyPixels Screenshot Resizer avoids the issue by working entirely in your browser. It decodes your image, crops or pads it with the Canvas API, and exports it, all on your device. You choose an iPad preset, such as iPad 13-inch 2064 × 2752, drag to position the crop, and download one file or a ZIP of many. Because nothing is uploaded, you can verify the claim yourself in the network tab of your browser's developer tools: no image request leaves the page.

The tool also warns about the problems that most often cause rejection after dimensions are correct, such as transparency in an Apple screenshot. That makes it useful as a pre-flight check even if you produce the original images elsewhere.

Compress iPad screenshots before you commit or upload

iPad screenshots are big. A 2064 × 2752 PNG of a detailed interface can easily run to several megabytes, and a full set in several languages multiplies that quickly. Large files slow down App Store Connect uploads on a poor connection, bloat your git repository if you version marketing assets, and make design handoff slower.

Compressing them is safe because the goal is to keep the pixel dimensions unchanged. Lossless PNG optimization rewrites the file with better compression settings and removes metadata, so the pixels are identical and the file is smaller. Lossy PNG quantization reduces the palette and can save much more, with differences that are invisible on most flat interface graphics but can band on gradients. Always compare the result at full size before you upload.

TinyPixels does this locally on macOS and Windows. Drop in a folder of exported screenshots, choose a preset, and the Rust compression engine rewrites each file while leaving the dimensions untouched. Pro is a one-time purchase, with no subscription, and nothing is sent to a server. If you keep a screenshots folder in your repository, the watch-folder feature can compress new exports automatically as they land.

A repeatable workflow for every release

1. Decide whether the build really supports iPad. If not, remove the iPad destination.
2. Capture or export at the 13-inch size first: 2064 × 2752 or 2048 × 2732.
3. Check the pixel dimensions of every file before you upload. A quick look in Preview's Inspector or any image tool is enough.
4. Flatten transparency and export as PNG or high-quality JPEG.
5. Compress locally and compare against the original at 100% zoom.
6. Upload the set to App Store Connect and review the scaled previews for smaller iPad models.
7. Add an 11-inch set only if the scaled previews look wrong.

Common iPad screenshot mistakes

Uploading iPhone screenshots to the iPad slot

App Store Connect will reject them on dimensions, but a stretched or letterboxed version that happens to match the pixel count will pass validation and then fail review because it does not represent the iPad experience.

Off-by-one export errors

Design tools sometimes export 2049 × 2733 when a layer has a half-pixel shadow. The upload fails with a dimensions error even though the image looks right. Always inspect the actual pixel size, not the frame size you set in the design file.

Forgetting landscape

If your iPad app supports landscape, your screenshots can be landscape too. Mixing orientations inside one set is permitted, but keep it intentional so the product page does not look inconsistent.

Leaving alpha in the PNG

Screenshots exported with a transparent background look fine in a preview tool that shows a checkerboard, then fail on upload. Flatten onto a solid color first.

Where this fits with iPhone and Google Play

Store assets are a small part of a larger asset pipeline. The iPhone sizes, including the 6.9-inch class that most teams design for first, are covered in our App Store screenshot size guide, and the Android side, where Google publishes constraints rather than a fixed list, is covered in our Google Play requirements article. Between them, the three guides cover every store screenshot a typical iOS and Android release needs.

Conclusion

iPad screenshots are easy once you separate the three questions: which size is required, how the image is produced, and how it is checked. Provide the 13-inch set, treat everything else as optional, verify exact pixel dimensions, flatten transparency, and keep the process local so unreleased interface never leaves your machine. A free in-browser resizer handles the geometry, and a local compressor handles the file size.

Frequently asked questions