Apple Wallet strip, logo and thumbnail sizes Strip, thumbnail, background, and the rest.

Apple specifies each image as an allotted space in points. Supply each one at the three scales current iPhones use, named strip.png, strip@2x.png and strip@3x.png. Wallet picks the scale for the screen.

“Allotted” is Apple’s word and it matters most for the logo: the 160×50pt is a maximum, and in Apple’s words “in most cases it should be narrower”. For the strip and background the allotment is the size to hit exactly; smaller is stretched, larger is scaled or cropped.

This is the one picture worth keeping in your head when designing a pass. If you want something to be seen, sharp, at a size people notice, it goes in the strip. Everything else is chrome.

The trap is that nothing tells you when you get this wrong. Put a thumbnail.png in a store card and Wallet ignores it. It is still in the bundle, still hashed into manifest.json and still signed. We shipped exactly that mistake once, which is why our builder now reads this table from one module and fails the build on a mismatch.

Wallet does no animation of any kind, so the strip is a still PNG. Anything text-like in it must survive being viewed small; the primary field is drawn over the strip on store cards, so leave room or leave the primary field empty and put the text in the artwork, which is what we do.

On an event ticket, Apple is explicit that the strip and the background are alternatives: “If you specify a strip image, do not specify a background image or a thumbnail.”

• Thumbnail. Apple: the aspect ratio “should be in the range of 2:3 to 3:2, otherwise the image is cropped.” Wallet rounds the corners itself, so fill the square rather than drawing a circle inside it. It is the only slot sized for a face that stays recognisable.
• Background. Apple: “The image is cropped slightly on all sides and blurred.” Fine detail, hairlines and text vanish. What survives is large areas of colour, which is how to design for it. Put a scrim in the artwork if your text colour has to read over a photo.
• Footer. 286×15pt, boarding passes only, just above the barcode.

• Design at @3x and export down. For a store-card strip that means a 1125×432px canvas, exported again at 750×288 and 375×144. Going the other way, upscaling a small original, is where soft passes come from.
• PNG only. Wallet reads PNG. A JPEG renamed to .png is not a PNG, and our viewer will say so.
• Keep the strip’s important content away from the left. On a store card the primary field is drawn over the strip, bottom left. If you put a name or a mark there, Wallet’s text will sit on top of it.
• Mind the file size of the strip. A photographic @3x strip can run to hundreds of kilobytes, and the pass is downloaded over whatever signal the person has. Flat colour and line art compress far better than photographs.
• Name the files exactly. strip@2x.png, not strip-2x.png or Strip@2x.PNG. Wallet looks for the exact names and ignores anything else without complaint.
• Test on a device. Every mock-up, including ours, is a reproduction of Wallet’s own drawing. The phone is the ground truth.

Our free .pkpass viewer opens any pass, lists every image with its real pixel size next to the allotment for its scale, and flags images the style cannot display, too many fields, and text Wallet will truncate. It checks against the same module this page is generated from.

For the rest of the format, including field limits and the behaviours Apple does not document, see the Apple Wallet pass guide. For the file itself, and why one sometimes refuses to open, see what a .pkpass file is.