How to download App Store screenshots in full resolution

Try it once and the problem is obvious. You open an App Store listing, right-click a screenshot, save it, and end up with a picture roughly 300 pixels wide. Blown up to anything useful it turns to mush. It is not a good copy of the artwork. It is not really a copy of the artwork at all.

This is not Apple being awkward. It's a side effect of how the page is built, and once you understand it, getting the real file is straightforward.

The page never has the real image

Apple serves listing artwork from an image CDN on mzstatic.com. Crucially, the CDN doesn't store one file per screenshot, it stores an original, and renders a resized copy on demand based on what the URL asks for. The URLs look like this:

https://is1-ssl.mzstatic.com/image/thumb/PurpleSource211/v4/…/WH_iOS_03.jpg/300x650bb.webp

Read the tail of that URL: 300x650bb.webp. That is an instruction. It says give me this image at 300×650, cropped, as WebP. The browser asks for a small WebP because a small WebP is what makes the page load quickly on a phone. That is the correct decision for a store page, and the wrong file for you.

So when you right-click and save, you aren't grabbing a compressed version of the original. You're grabbing a completely different file that the CDN generated, on the fly, to Apple's specification rather than yours.

Asking for the original instead

Change the tail of the URL and the CDN renders a different size. Ask for 1284x2778bb.png and you get the image at 1284×2778, as a PNG. That is the full-resolution original.

The obvious next question: how do you know it's 1284×2778 and not something else? You can't guess, and guessing high doesn't work, asking for more pixels than the source has just gets you an upscaled, blurry file that claims the right dimensions.

Fortunately Apple tells you. Buried in the page's HTML is a JSON blob, look for a script tag with the id serialized-server-data, and inside it, every piece of artwork is described like this:

{
 "$kind": "Artwork",
 "template": "https://is1-ssl.mzstatic.com/…/WH_iOS_03.jpg/{w}x{h}{c}.{f}",
 "width": 1284,
 "height": 2778
}

There it is. The template has literal {w} and {h} placeholders, and the node hands you the true native dimensions alongside. Fill the template with the image's own width and height and the CDN returns exactly the file the developer uploaded.

A detail worth knowing: the filenames survive

Look again at that URL and you'll notice something useful, WH_iOS_03.jpg. Apple's CDN paths preserve the original artwork filename from the upload.

In practice this is more valuable than it sounds. Real listings tend to carry names like EC-15030-WH-UK-Offer-R30-CPP-UK-iOS-6.5-1284x2778-S01.jpg, which encodes the campaign code, the market, the device class and the slide number. If you're trying to reconcile ripped assets against a design team's source files or a campaign brief, those names do a lot of the matching for you.

The trap: don't grab the wrong app's icon

One warning, because it's an easy and embarrassing mistake.

The app icon is not reliably in that JSON blob, the header where it's displayed is rendered client-side, and is empty in the raw HTML. Meanwhile the same page carries a “You Might Also Like” shelf, packed with the icons of other apps, in an almost identical JSON shape.

So a naive scrape that searches the page for something icon-shaped will happily return a competitor's icon. We know, because the first version of our own tool did exactly that, and very nearly handed a rival's logo to a client as their own.

The fix is to stop scraping and start asking. Apple runs a public lookup endpoint that is authoritative for a given app ID:

https://itunes.apple.com/lookup?id=465712788&country=gb

That returns the app's real metadata, including its icon URL, and because it's keyed on the app ID, there is no possibility of picking up the neighbour's artwork by accident. Note that this endpoint sometimes returns an empty screenshot list, so it isn't a replacement for parsing the page. Use the page for screenshots, the lookup for the icon.

What quality you actually end up with

Let's be straight about this, because a lot of tools oversell it.

What you get back is the exact file the developer uploaded to App Store Connect, no better. Apple stores those as JPEG. Our tool exports them as PNG, which prevents a second round of lossy compression being applied on the way out, but it cannot reverse the compression already baked into the source. There is no upscaling and no recovery of detail that was never there.

For screen use, decks, audits, competitive teardowns, rebuilding a listing, this is exactly what you want. For print, it isn't, and no amount of clever URL manipulation will change that. Go and find the design files.

Doing it without the manual work

Everything above is mechanical, which is why we automated it. Paste a listing URL into the tool and it reads the JSON, pulls every artwork node at its own native dimensions, fetches the icon from the lookup API, and hands you a ZIP with a manifest mapping each file back to its source.

If you'd rather understand the Play Store side too, that works on the same principle but a completely different data structure, we've written that up separately.