Common Passport Scanning Errors (and How to Avoid Them)

When automated passport reading fails, the cause is almost never the document or the OCR engine: it's how the photo was taken. And because a passport self-verifies through its check digits, the failure is usually honest — the system says it couldn't read — rather than silent.

Here's the list of causes, ordered by frequency, with the fix for each.

1. Glare on the laminate

The number one cause, by a wide margin. A passport data page is laminated and usually carries holographic elements designed precisely to catch light. A front-facing flash bounces straight off the two MRZ lines and erases them.

The tell: the rest of the page reads perfectly and only the bottom strip fails.

Fix:

• Turn the flash off. It almost always makes laminated documents worse.
• Tilt the document 10 or 15 degrees, or move yourself. Reflection is specular: a small angle change shifts it off the text.
• Diffuse, side-on light — next to a window beats any lamp pointed straight at it.

2. A cropped MRZ

The second most common error and the easiest to prevent. The user frames "the passport" by centring the photo and the name, and leaves the two lines at the foot out — or partly out.

Without a complete MRZ there's no check-digit validation. You can still read the visual zone, but you lose the arithmetic confirmation that makes the result trustworthy.

Fix: frame the whole page, with visible margin on all four sides. In a capture UI, draw a guide with the data page's aspect ratio and explicitly mark where the bottom two lines must sit. A shaded rectangle over the MRZ area, labelled "both of these lines must be fully visible", eliminates almost all of these.

3. Insufficient resolution

MRZ characters are small: 44 per line across the width of the page. When the image is low-resolution, each character gets very few pixels and the fine distinctions — 0 against O, 1 against I — become impossible.

Fix: aim for at least 1200 pixels wide across the data page; 1600 or more is comfortable. Watch for two common traps:

• Messaging-app compression. A passport arriving via WhatsApp may be 800 px wide with JPEG artefacts. If your workflow receives documents that way, ask for the original file.
• Client-side downscaling. Many apps shrink images before upload to "save bandwidth". With a 10 MB limit there's no need: send the full photo.

And a counterintuitive warning: enlarging a small image does not recover information. If your pipeline upscales before sending, you may be degrading an image that was already legible. Send the original bytes.

4. Shadows and uneven light

The shadow of the phone itself, or of the hand holding the document, falling across part of the page. The OCR reads the lit half fine and fails on the other.

Fix: light from behind or beside the camera, not in front of it. If you're shooting from above with the document on a desk, watch where your own shadow lands.

5. Heavy rotation and perspective

The MRZ is read as two horizontal lines. A badly skewed document, or one photographed at an angle so the page comes out as a trapezoid, complicates segmenting those lines.

Fix: camera parallel to the page, not diagonal. Slight rotation corrects itself; a 30-degree angle doesn't.

6. A photo of a screen

Someone opens the passport PDF on a laptop and photographs the screen. The result has moiré, banding and glare — the worst possible combination.

Fix: if the document is already digital, upload it as a file. The API accepts URL and base64 submission precisely so a document that was born digital never has to pass through a camera.

7. Worn passports

The legitimate case: documents with eight or nine years of use, laminate scratched right over the MRZ, or creases crossing the lines.

Here there is a physical limit. If the characters aren't there, no engine can invent them — and we'd rather tell you than hand back a made-up passport number. When the MRZ is damaged, the visual zone remains legible and supports capture with manual review.

What a well-handled failure looks like

Our API returns 422 LOW_IMAGE_QUALITY when the image doesn't permit a reading that verifies, with the list of fields that couldn't be read:

{
  "success": false,
  "code": "LOW_IMAGE_QUALITY",
  "missing_fields": ["mrzLine2"],
  "extraction_id": "clx7f2k..."
}

And the token is refunded: an unreadable image doesn't consume balance.

That missing_fields is what turns an error into an instruction. Instead of "error processing document", your UI can say:

We couldn't read the two lines at the foot of the passport. Please retake the photo making sure they appear in full, without glare.

That's the difference between a user who retries successfully and one who gives up.

The list, for your capture screen

If you're going to put instructions on screen, these five resolve the vast majority of cases:

1. Whole page, with both lines at the foot visible
2. No flash
3. Side lighting, no shadows across the page
4. Camera parallel to the document
5. The original photo — not cropped, not compressed

Try it

The free demo processes a passport with no signup: the quick way to see how the system responds to your own capture conditions. If you already have a transcribed MRZ and want to check whether it's consistent, the MRZ validator recomputes the check digits for free.

For handling these cases in code, with retries and error codes, see How to integrate a passport OCR API.