Why your passport photo keeps getting rejected (it's the file, not the picture)

If you've ever uploaded a passport photo to a government portal and gotten a vague "photo rejected" error, the problem usually isn't the photo. It's the file.

I've been running IDPhotoSnap, a free browser-based passport photo tool, for a few months now. The single most common support question is some flavor of "my photo looks fine, why does the portal say it's wrong?"

The answer almost always lives in the file's metadata, not the visible image. Here's the breakdown.

The 8 file-level rejection reasons

1. File size out of range

Most embassy portals enforce strict caps:

• US State Department DS-160: 240 KB max
• UK passport portal: 50 KB - 10 MB
• Schengen visa portals: 240 KB - 6 MB depending on country
• India passport seva: 20 KB - 300 KB

A modern phone shoots 4-8 MB by default. The portal rejects before any human sees the picture.

2. Wrong DPI

DPI is metadata. It doesn't change pixel data — it just labels the image as "intended for printing at this density". Phone cameras tag photos at 72 DPI. Embassy print pipelines require 300.

// In a JPEG, DPI lives in the JFIF header (bytes 13-18) or EXIF tag 0x011A.
// Changing it does NOT recompress or resize - just rewrites those bytes.

You can verify in any terminal:

identify -format "%x x %y\n" photo.jpg  # ImageMagick
# Output: 72x72  ← needs to be 300x300

The pixel content is identical. The metadata tag is what trips the validator.

3. Wrong dimensions

Every country uses different size requirements:

Country	Size
US	600×600 px (2×2 inches)
Schengen	35×45 mm
UK	35×45 mm at 600×750 px minimum
India	51×51 mm at 600×600 px
Japan	35×45 mm at 413×531 px

A photo that passes for one country fails for another. There's no universal size.

4. Wrong format (HEIC, WebP, PNG)

iPhones save HEIC by default. Android sometimes saves WebP. Most government portals only accept JPG. About half also reject PNG.

The HEIC → JPG conversion can be done client-side with libheif compiled to WASM:

import { decode } from 'libheif-js'

async function heicToJpeg(file) {
  const buf = await file.arrayBuffer()
  const decoder = new Decoder()
  const data = decoder.decode(new Uint8Array(buf))
  // ... draw onto canvas, export as JPEG with quality 0.92
}

5. Background isn't pure white

Background validators look for RGB(255,255,255) ± a small delta. Common failures:

• Off-white walls (255, 250, 245)
• Window light gradient across the wall
• Soft shadow behind the head

For true compliance, replace the background entirely. ML segmentation models like MODNet (~25 MB ONNX) run in-browser via onnxruntime-web.

6. Compression artifacts

Quality 60% JPEG produces visible block artifacts. Validators sometimes flag low SSIM. Recompress at quality 90-95%, target the size limit by re-trying with smaller pixel dimensions if needed — never below the size threshold.

7. Color profile mismatch

Display-P3 photos from iPhones can fail validators that expect sRGB. Convert before export:

ctx.imageSmoothingEnabled = true
ctx.drawImage(img, 0, 0)
const data = ctx.getImageData(0, 0, w, h)
// canvas defaults to sRGB - the act of drawing converts it

8. Embedded thumbnail mismatch

Obscure but real: some portals compare the EXIF thumbnail to the main image. If they differ (e.g., you cropped the main but the thumbnail is the original), it's flagged as edited. Strip EXIF entirely:

// Re-encoding via canvas removes all EXIF/XMP/IPTC metadata
const clean = canvas.toBlob(blob => ..., 'image/jpeg', 0.95)

Why a browser-only tool makes sense here

All the operations above are pure pixel manipulation. None of them require server compute. None of them require AI in the cloud. Even background replacement runs locally with onnxruntime-web at ~2-5 seconds per image on a mid-range laptop.

Uploading a photo of your face to a third-party service to do work that runs fine in WebAssembly is bad architecture and worse privacy.

If you want to see this approach in action, IDPhotoSnap handles all 8 of these issues for 85+ countries with zero uploads. There's a separate Photo Rejected hub that diagnoses an existing rejected photo and fixes the specific issue, also entirely client-side.

Lesson

When a government portal rejects "a fine-looking photo," 90% of the time it's reading the file's metadata, not the picture. Engineering for this is mostly about being deliberate about what you write into the JPEG header — DPI tag, dimensions, color profile, embedded thumbnails — not about the pixels themselves.

FAQ

Q: Why do passport portals not give specific error messages?
A: They run a chain of validators (size → format → DPI → dimensions → background) and abort on the first failure. Some surface only the last failure code. Many surface nothing useful at all.

Q: Will printing the photo fix DPI?
A: Yes for in-person submission. No for online portals — they read the file metadata, not the print.

Q: Can I just convert HEIC to JPG and call it done?
A: Often yes for size and format checks. But the converter often loses the DPI tag (defaults to 72) and the dimensions stay phone-default, so 50% of the time you also need a resize and a DPI rewrite.

Q: Is server-side processing ever needed for this?
A: Not for 99% of cases. Background removal is the only borderline case (large model file). Everything else fits comfortably in Canvas + a few KB of code.