DEV Community: Jason T.

App Store and Google Play screenshot sizes in 2026 (and the rules that get uploads rejected)

Jason T. — Thu, 01 Oct 2026 06:28:38 +0000

Every release I end up re-checking the same thing: which screenshot sizes does App Store Connect want this year, and what will Google Play reject? Here are the official numbers in one place, plus the rules that trip people up. Sources are linked at the bottom.

App Store: what you actually have to provide

Apple accepts screenshots only at exact pixel sizes. A few pixels off and the upload fails.

Display	Accepted portrait sizes (px)	Required?
iPhone 6.9"	1320×2868, 1290×2796, 1260×2736	Yes, for iPhone apps (or provide 6.5")
iPhone 6.5"	1284×2778, 1242×2688	Only if you don't provide 6.9"
iPhone 6.3"	1206×2622, 1179×2556	No (scaled from 6.5")
iPhone 6.1"	1170×2532, 1125×2436, 1080×2340	No (scaled from 6.5")
iPad 13"	2064×2752, 2048×2732	Yes, if your app runs on iPad
iPad 11"	1668×2420, 1668×2388, 1640×2360, 1488×2266	No (scaled from 13")

Landscape versions of each size are accepted too. In practice, if you ship one iPhone set at 6.9" and, for iPad apps, one set at 13", the smaller displays are scaled from those.

Other rules:

1 to 10 screenshots per display size
JPG or PNG
No alpha channel or transparency. This one bites people who export PNGs from design tools or from <canvas>: a canvas PNG always has an alpha channel, even when every pixel is opaque. Exporting JPEG avoids it entirely.

Google Play: rules instead of a size list

Play doesn't publish a fixed list. Phone screenshots must be:

JPEG or 24-bit PNG, no alpha
Each side between 320 px and 3,840 px
The long side no more than twice the short side. A tall modern phone capture (for example 1080×2400, which is 2.22:1) breaks this rule, so you can't upload raw screenshots from many current Android phones without adding padding or a background.

To be eligible for Play's large-format recommendation slots, apps need at least four screenshots at 1080 px or more, in 9:16 portrait (1080×1920 or larger) or 16:9 landscape.

The content guidelines also matter if you add marketing captions:

Taglines should take up no more than 20% of the image
Avoid performance, ranking, price or promo claims: "Best", "#1", "Top", "New", "Free", "Discount", "Sale", "Million Downloads"
No calls to action like "Download now" or "Install now"

The feature graphic is separate: 1024×500, JPEG or 24-bit PNG, no alpha.

A layout that satisfies both stores

What has worked for me is a caption band at the top and the real screenshot below it, scaled to fit, never stretched:

// caption band: 18% on Play (under the 20% limit), ~22% on the App Store
const capH = Math.round(target.height * (target.store === "play" ? 0.18 : 0.22));
const pad = Math.round(target.width * 0.08);
const boxW = target.width - pad * 2;
const boxH = target.height - capH - pad;
const scale = Math.min(boxW / shot.width, boxH / shot.height); // fit, keep aspect ratio
const w = Math.round(shot.width * scale), h = Math.round(shot.height * scale);
const x = Math.round((target.width - w) / 2);
const y = capH + Math.round((boxH - h) / 2);

Render it on a canvas at the exact target size, then canvas.toBlob(cb, "image/jpeg", 0.92) so there is no alpha channel to worry about.

I got tired of doing this by hand, so I built a small browser tool that does exactly this: you add captions to your screenshots and it exports every size above, checks them against these rules (including flagging the Play-banned words in your captions), and nothing gets uploaded: App Store & Google Play screenshot generator. Disclosure: I made it. Previews are free; downloading the full set is a one-time payment.

Sources

Both checked October 2026. If you've hit a rejection reason that isn't covered here, I'd like to hear it in the comments.

Hitting a file-size window with canvas.toBlob: fitting passport photos into 54–240 KB

Jason T. — Wed, 30 Sep 2026 19:21:22 +0000

Government photo upload forms are strict about file size, and they are strict in both directions. The US DS-160 visa form wants a JPEG of at most 240 KB with a compression ratio no higher than 20:1. China's online visa form wants 40–120 KB. Upload a 30 KB file and it gets rejected for being "too compressed"; upload 300 KB and it is too big.

Most people fix this by re-saving in an image editor until it works. When you build a tool that does it automatically, it turns into a neat little search problem. Here is how I handle it in the browser, with no server involved.

Step 1: turn the rules into a byte window

A "compression ratio" limit is really a minimum file size in disguise. The ratio compares the raw bitmap size to the compressed file size:

raw bytes = width × height × 3        (24-bit RGB)
ratio     = raw bytes / file bytes

For a 600×600 DS-160 photo the raw bitmap is 1,080,000 bytes, so a ratio of at most 20:1 means the file must be at least 54,000 bytes. Put that next to the stated maximum and the rules become a window:

export function byteBounds(spec: PhotoSpec) {
  const d = spec.digital;
  if (!d) return undefined;
  const raw = spec.output.widthPx * spec.output.heightPx * 3;
  const fromRatio = d.maxCompressionRatio ? Math.ceil(raw / d.maxCompressionRatio) : 0;
  return { minBytes: Math.max(d.minBytes ?? 0, fromRatio), maxBytes: d.maxBytes };
}

One more gotcha: official pages say "KB" without saying whether they mean 1000 or 1024 bytes. For a minimum I use ×1024, and for a maximum ×1000. The file then passes whichever way the validator reads it.

Step 2: binary-search the JPEG quality

canvas.toBlob(cb, "image/jpeg", quality) gives you exactly one knob. File size grows with quality, roughly monotonically, so binary search works well. I inject the encoder so the logic can be unit-tested without a canvas:

const Q_MIN = 0.3;
const Q_MAX = 1;

export async function fitJpeg<T extends { size: number }>(
  encode: (quality: number) => Promise<T>,
  { minBytes, maxBytes }: { minBytes: number; maxBytes: number },
  iterations = 8,
) {
  const best = await encode(Q_MAX);
  if (best.size <= maxBytes) {
    return best.size >= minBytes ? { ok: true, result: best } : { ok: false, reason: "too-small", result: best };
  }
  const worst = await encode(Q_MIN);
  if (worst.size > maxBytes) return { ok: false, reason: "too-large", result: worst };

  let lo = Q_MIN, hi = Q_MAX, fit = worst;
  for (let i = 0; i < iterations; i++) {
    const q = (lo + hi) / 2;
    const r = await encode(q);
    if (r.size <= maxBytes) { fit = r; lo = q; } else { hi = q; }
  }
  return fit.size >= minBytes ? { ok: true, result: fit } : { ok: false, reason: "too-small", result: fit };
}

A few design choices:

Aim for the largest file that fits, not the first one. Officers look at these photos. The more quality you keep under the cap, the fewer "blurry photo" rejections you get.
Check the extremes first. If quality 1.0 already fits, stop there. If quality 0.3 is still too large, the pixel dimensions are wrong and no quality setting will fix it. Report that instead of looping.
Eight iterations is plenty. That narrows quality to about 0.003, well below the point where file size visibly changes.
"Too small" is a real failure. A flat, mostly white photo can compress below the minimum even at quality 1.0. It's better to report that clearly than to pad the file with junk bytes.

In the browser the encoder is just a promise wrapper:

const toBlob = (c: HTMLCanvasElement, q: number) =>
  new Promise<Blob>((res, rej) => c.toBlob((b) => (b ? res(b) : rej(new Error("encode failed"))), "image/jpeg", q));

const fit = await fitJpeg((q) => toBlob(photo, q), byteBounds(spec)!);

Step 3: test it without a browser

Because the encoder is injected, the tests use a fake whose size is a function of quality:

const fake = (bytesAt: (q: number) => number) => async (q: number) => ({ size: bytesAt(q), q });

it("returns the largest file under the cap", async () => {
  const r = await fitJpeg(fake((q) => Math.round(400_000 * q)), { minBytes: 54_000, maxBytes: 240_000 });
  expect(r.ok).toBe(true);
  expect(r.result.size).toBeLessThanOrEqual(240_000);
  expect(r.result.size).toBeGreaterThan(235_000);
});

Where the numbers come from

The limits above come from the official pages (travel.state.gov for DS-160, the Chinese visa application service for China). I keep them, with sources, in an open dataset: passport-photo-requirements on GitHub (CC BY 4.0, JSON). There is also a side-by-side table of requirements by country.

This code runs inside pixtidy, a passport and visa photo maker I built. Face detection, cropping and this size fitting all happen in the browser, so the photo never leaves the device. If you've run into other odd government upload rules, I'd like to hear about them in the comments.

Checking passport photos against government specs in the browser with MediaPipe

Jason T. — Wed, 30 Sep 2026 17:11:26 +0000

Government photo rules read like a spec sheet. The DS-160 (US visa) wants a square JPEG between 600×600 and 1200×1200 px, at most 240 KB, with the head (chin to top of hair) taking 50–69% of the image height and the eyes 56–69% up from the bottom. The Chinese visa wants 354×472 px, 40–120 KB, and the crown 10–70 px below the top edge. India's OCI photo must have a light background that is not white.

A spec sheet can be turned into code, so I built a checker that runs entirely in the browser: the photo never leaves the device, and there's no server-side inference to pay for. This post walks through the pipeline and the parts that were harder than expected.

The stack

@mediapipe/tasks-vision with two models, served from our own origin:
- FaceLandmarker (478 landmarks + blendshapes + a facial transformation matrix)
- ImageSegmenter with the selfie segmentation model
Plain <canvas> for rotation, cropping, pixel statistics and JPEG encoding
No uploads and no third-party scripts

const fileset = await FilesetResolver.forVisionTasks(WASM_PATH); // self-hosted wasm
const face = await FaceLandmarker.createFromOptions(fileset, {
  baseOptions: { modelAssetPath: "/models/face_landmarker.task", delegate },
  runningMode: "IMAGE",
  numFaces: 2, // we need to know if there's more than one
  outputFaceBlendshapes: true,
  outputFacialTransformationMatrixes: true,
});

numFaces: 2 is deliberate. If you ask for one face you can't tell a clean portrait apart from a photo with someone standing behind you, and "no other people in the photo" is a rule almost everywhere.

Step 1: level the eyes before measuring anything

Phone photos are rarely level. Every measurement downstream (head height, eye line, crop box) assumes an upright head, so the first step is to rotate around the midpoint between the irises:

const roll = rollFromEyes(irisLeft, irisRight); // atan2 of the eye line, in degrees
if (Math.abs(roll) > 1) {
  source = rotate(source, roll, cx, cy);
  res = face.detect(source); // re-run landmarks on the levelled image
}

Is rotating allowed? For in-plane tilt, yes: the US State Department's own photo tool rotates. What you must never do is warp or retouch the face. After rotating, the canvas corners are blank, so the crop search is constrained to rectangles that stay inside real pixels.

Step 2: finding the top of the head (landmarks stop at the forehead)

This was the least obvious part. Every official spec measures head height from the chin to the crown (top of the hair), but the face mesh stops at the hairline. Using the forehead landmark underestimates head height by roughly 20%, and that is enough to fail a 50–69% window.

The fix is the segmentation mask. Scan down from the top of the image inside the face's column band and take the first row where several columns are "person":

export function findCrownY(mask, w, h, x0, x1, maxY, minColumns = 2) {
  for (let y = 0; y <= maxY; y++) {
    let hits = 0;
    for (let x = x0; x <= x1; x++) if (mask[y * w + x] === PERSON) hits++;
    if (hits >= minColumns) return y;
  }
}

Two details matter:

Only scan the middle 60% of the face width, so shoulders and raised hands at the edges don't count as "head".
Require a minimum run of columns (about 10% of the face width) so a few stray mask pixels don't pull the crown up.

If the mask finds nothing (a bald head against a white wall can blend in), fall back to forehead − 0.2 × (chin − forehead).

Model size matters for a page people open on their phone. I started with the 16 MB multiclass segmenter (hair, face skin, body, background) and replaced it with the ~250 KB person/background selfie model, which treats hair as "person". On my test portraits the crown positions agreed within about 1.5% of head height, which is well inside every spec's tolerance.

Step 3: solve for the crop, don't guess it

With the crown, chin, eye line and face center known, the crop is a small constraint problem. Each spec gives some of:

head height as a fraction of the image height (e.g. [0.50, 0.69])
eye line as a fraction from the bottom (e.g. [0.56, 0.69])
crown margin from the top edge (China: 10–70 px of 472)
output size and aspect ratio

Pick the scale that puts the head at the middle of its allowed range, place the eyes in the middle of theirs, center horizontally, then check that the rectangle still sits inside the image. If the person is too close to the camera, no rectangle fits, and we tell them to step back instead of silently producing a bad crop.

Some specs publish no head-size number at all (the UK digital visa photo, New Zealand passport). For those we use a clearly labelled "recommended framing" rather than inventing a rule.

Step 4: the checks

Everything after the crop is measured on the output-sized image, because that is what the government system will see.

Rule	Signal
Eyes open	blendshapes `eyeBlinkLeft/Right` < 0.5
Mouth closed	`jawOpen` < 0.25, plus the lip gap relative to face height
Facing the camera	yaw from the facial transformation matrix, warn at 5°, fail at 10°
Background	mean and standard deviation of luma over non-person pixels
Lighting	mean luma of the face box within 70–210
Sharpness	variance of the Laplacian on the face box, resized to 256 px wide

One surprise: pitch from MediaPipe's transformation matrix reads 10–17° on perfectly frontal official sample portraits. Failing on pitch would reject good photos, so pitch only ever warns.

Background checks depend on the spec: "white" (US) needs a mean above 200 with low variance, while OCI needs a light background that is not white. The same pixels can be a pass for one document and a fail for another, which is why every check reads its thresholds from the spec object instead of hard-coding them.

Step 5: hitting the file-size window

Many portals have a minimum and maximum file size (China: 40–120 KB, Australia: 70 KB–3.5 MB) and some cap the compression ratio. canvas.toBlob(cb, "image/jpeg", q) is monotonic enough in q that a binary search works:

export async function fitJpeg(encode, { minBytes, maxBytes }, iterations = 8) {
  const best = await encode(1);
  if (best.size <= maxBytes) return best.size >= minBytes ? ok(best) : tooSmall(best);
  const worst = await encode(0.3);
  if (worst.size > maxBytes) return tooLarge(worst);
  let lo = 0.3, hi = 1, fit = worst;
  for (let i = 0; i < iterations; i++) {
    const q = (lo + hi) / 2, r = await encode(q);
    if (r.size <= maxBytes) { fit = r; lo = q; } else { hi = q; }
  }
  return fit.size >= minBytes ? ok(fit) : tooSmall(fit);
}

encode is injected so the search is unit-tested without a canvas. Eight iterations are enough to land within a few KB of the limit, and we take the largest file that fits, because a bigger file means less compression and better quality.

What I'd tell anyone building something similar

Store the source for every number. Each spec in the code links to, and has an archived copy of, the government page it came from. Requirements disagree across pages (the Vietnam e-visa portal states both a 2 MB and a 10 MB limit) and you need to be able to say why you chose one.
Test on official sample photos. Governments publish "acceptable" examples. If your checker fails them, your thresholds are wrong, and that is how the pitch issue showed up.
Never retouch. It's tempting to "fix" backgrounds or smooth skin, but US, UK, Australian and New Zealand guidance explicitly rejects edited photos. Crop, level and resize only.

The spec data (18 documents, with sources) is open on GitHub: tensam/passport-photo-requirements. The checker itself is at pixtidy.com. The check is free; I'm the developer, so feedback on edge cases (glasses glare, very dark skin against a white wall, babies) is very welcome.