How Blur Affects Passport OCR: Testing OCR Accuracy on Blurry Passport Images

Blur is one of the most common image-quality problems in passport OCR. When a passport photo is out of focus, OCR may lose individual characters, whole text fields, or the entire MRZ — but not all parts of the document degrade at the same rate. In this experiment, we tested how increasing image blur affects passport OCR, comparing the human-readable visual zone (VIZ) with the machine-readable zone (MRZ).

How Does Blur Affect Passport OCR?

These σ values describe the synthetic Gaussian blur applied to the image; they are not a direct measurement of camera defocus.

The question

Most discussions of document OCR quality boil down to a vague rule of thumb: "blurry photos don't work." That's true but not useful — it doesn't say how much blur is too much, whether every part of a document fails at the same point, or whether the OCR engine itself can tell you it's in trouble. We wanted a more precise version of the question:

At what point does blur actually make a passport unusable for OCR — and can OCR confidence detect it early enough?

Two follow-up questions came with it:

• Do the visual zone (VIZ — the human-readable printed fields) and the machine-readable zone (MRZ) degrade the same way, or does one fail first?
• Can OCR confidence be used as a stand-in for image-quality checking, or does it need to be treated as a separate signal?

Experiment

The source image is a publicly available Norwegian specimen passport (1700×1200 px, JPEG) — a standard specimen document with no real personal data, printed at roughly 300 dpi with a machine-readable zone in OCR-B. We applied Gaussian blur to the same base image at 14 radii (σ = 0, 0.2, 0.4, 0.6, 0.8, 1, 1.5, 2, 2.5, 3, 3.5, 4, 5, 6 px) and ran every resulting image through the OCR pipeline we use for document processing — detection, orientation classification and recognition, with no additional preprocessing at any step.

VIZ and MRZ were scored separately. For MRZ, each recognized line was compared character-by-character against the σ=0 baseline (Levenshtein distance, normalized to accuracy). For VIZ, we tracked the raw count of detected text fragments and the confidence the OCR engine reports for each one — 48 fragments were detected at σ=0, which we treat as the reference count.

What happened to VIZ

Up to σ=2.5 px, detection was essentially untouched: all 48 text fragments were found at every step. Then the detector's output collapsed within half a blur unit.

At σ=3 px, VIZ detection dropped from 48 to 19 fragments — while the MRZ was still essentially intact.

The degradation is not gradual. VIZ detection remains essentially unchanged and then collapses in a narrow band around σ≈2.5–3 px. The fields lost first are the smallest: bilingual sub-labels printed under each heading ("Type · Tiipa/", "Kjønn · Sohkabealli/"). The larger primary fields — surname, given names, dates, passport number — survive somewhat longer but are also shrinking toward 4–5 detected pixels of stroke width by σ=4.

This is the key asymmetry the rest of this piece is about: VIZ fails first, while the MRZ retains useful, machine-readable information under significantly stronger blur.

MRZ behaved very differently

This is the central result of the experiment. The MRZ remained practically readable through σ≈4 px, with the first character-level discrepancy appearing around σ=3–4 px — a blur radius where VIZ detection had already dropped to a third of its baseline fragment count. The major breakdown occurred between σ=4 and σ=5.

Line 2 (the document-number line) briefly lost letter case around σ=3–4 ("CCC" read as "ccc") — a character-level scoring artifact, not a practical reading error, since MRZ parsing is case-insensitive by design. We still counted it against accuracy for consistency, which is why the table below reads ≈93–100% at σ=4 rather than a flat 100%. The real break happens between σ=4 and σ=5: line 1 stops being detected as a full string at all, and line 2's accuracy drops from 93% to 36% in a single step. At σ=6 both lines fragment into disconnected tokens and the MRZ is no longer usable.

For a rough side-by-side, here is the same blur axis scored on each zone's own metric — the two columns aren't directly comparable numbers (fragment count vs. character accuracy), but the gap between when each zone starts failing is the point:

Why does MRZ survive longer?

The gap has a physical explanation, not just an empirical one. We measured the MRZ zone directly on the source image: character (cap) height ≈33 px, with a median glyph stroke width of 5–6 px. The VIZ fields use a considerably smaller, thinner multilingual font for most labels. Gaussian blur removes detail at a scale set by σ. In this experiment, the larger MRZ strokes remained separable under substantially stronger blur than the thinner VIZ strokes — MRZ tolerating blur to about σ≈4–4.5 before it starts breaking down, versus σ≈2.5–3 for the smaller VIZ text. This is consistent with the observed difference in their breakdown points.

The surprising result: confidence isn't a blur detector

If OCR confidence tracked image sharpness, it should fall as σ rises. It didn't, at least not in the range where the image is still easily readable to a human. Averaged over nine VIZ fields that were detected at every step from σ=0 to σ=2.5:

At σ=0 the average confidence was 0.982. At σ=0.8 it dropped to 0.954. At σ=1.5–2.5 it recovered to about 0.979 — close to, and briefly above, several of the earlier readings. The sharpest image in the set did not produce the highest confidence.

A recognizer's confidence answers "how confident am I in this recognition?", not "how sharp is this image?"

One plausible mechanism: at σ=0 the recognizer also sees every fine-grained texture on the page — the guilloché security pattern, JPEG compression noise, micro-contrast around thin strokes — and treats some of that texture as visual noise around the letterforms. A small amount of blur (≈1–1.5 px) suppresses that texture without yet touching the strokes themselves, which is consistent with the local dip and recovery we see. We wouldn't generalize this to other OCR engines or images from a single run, but it's enough to say confidence shouldn't be read as a sharpness proxy.

What should a document scanner actually check?

This experiment doesn't, by itself, justify a specific accept/reject threshold in production — one document, one synthetic blur kernel, one OCR pipeline. Gaussian blur only approximates part of what a bad capture looks like (see Limitations below). What it does support is a design conclusion: OCR confidence alone is not a sufficient quality gate.

When a blurry passport image is uploaded to a document scanner, the system needs to decide whether the image is good enough to process before OCR runs, or only after recognition already came back incomplete. Based on what we saw here, a more robust check would combine several independent signals rather than relying on any one of them:

• Raw image sharpness measured directly on the photo (for example, Laplacian variance), computed before OCR runs.
• The number of detected text regions relative to what a valid document of that type should contain.
• Whether the MRZ zone specifically was recognized as two complete, checksum-consistent lines.
• Agreement between VIZ and MRZ where the same field appears in both (name, dates, document number).
• OCR confidence as one input among these signals, not the deciding one.

Turning any of this into a fixed production threshold — "reject below σ-equivalent X" — would need a proper series run on real phone-camera captures of real documents, across lighting, camera models and genuine motion blur, not a single synthetic Gaussian sweep on one specimen image. That's a natural next step, not a conclusion of this experiment.

What this means for automated document processing

A document OCR pipeline should distinguish between recognition quality and image quality. A recognizer can be highly confident about the characters it detects while the image itself is already losing information — the two are not the same measurement, and this experiment is one concrete case where they visibly diverge.

For automated workflows built on passport OCR — hotel check-in, car rental, travel onboarding and identity verification — this makes pre-OCR quality assessment useful in its own right: catching an out-of-focus passport photo before it's processed can prevent incomplete extraction and give the guest a chance to retake the photo, rather than surfacing a partial or wrong result downstream.

Limitations

This is not a benchmark of OCR engines. It's a study of one pipeline's behavior on one document under one controlled distortion — it is not a claim that any particular OCR engine withstands 4 px of blur in general, and results will differ across engines, fonts, document types and image resolutions.

Gaussian blur is only an approximation of real camera defocus. A real out-of-focus or low-quality photo typically also carries motion blur, perspective distortion, sensor noise, JPEG compression artifacts, uneven lighting and glare — none of which were modeled here, and any of which could shift the breakdown point in either direction.

Conclusion

Blur affects different parts of a passport at very different rates. In this experiment, VIZ text detection began degrading around σ≈2.5–3 px, while the MRZ remained readable until roughly σ≈4–5 px.

The experiment also showed that OCR confidence is not a reliable proxy for image sharpness: confidence did not decrease monotonically as blur increased.

For automated passport OCR, image-quality assessment is therefore better treated as a separate part of the pipeline, alongside recognition, MRZ validation and cross-field consistency.

This was a small controlled experiment, not a universal blur threshold. The next step would be testing real smartphone captures across different cameras, lighting conditions and types of blur.