Passport OCR API for ICAO 9303 MRZ & Field Extraction

Passport OCR is optical character recognition tuned specifically for the layout of passport data pages. A generic OCR engine treats a passport like any other document: it returns a flat list of text blocks with no knowledge of which line is the document number, which is the date of birth, or where the Machine Readable Zone starts and ends.

A passport OCR API does two things on top of that. First, it locates and parses the MRZ at the bottom of the data page using the strict ICAO 9303 format, validating the check digits embedded in the string. Second, it reads the visual fields above the MRZ and returns them as named keys (passportNumber, name, birthDay, expiryDay, and so on) in a structured JSON response. You stop writing regular expressions against raw text and start consuming a fixed-shape object.

The MRZ is the band of two or three OCR-A-font lines at the bottom of every ICAO 9303 compliant travel document. It encodes the passport number, the issuing country, the holder's name (separated by chevron < characters), the date of birth, the sex, the expiry date and the nationality — plus five separate check digits that mathematically verify the surrounding data.

PicToText decodes the MRZ in three steps. It first segments the lines using the OCR-A character set, then maps each fixed-width field to its meaning per the ICAO 9303 specification, then recomputes the check digits and compares them to the printed values. If a check digit fails, the engine surfaces the value it could read but flags the underlying MRZ string in the response so your application can decide whether to retry, ask the user to re-capture, or escalate the document to manual review.

The API supports every ICAO 9303 compliant travel document, which covers booklet-style passports (TD3 — two MRZ lines of 44 characters) and card-style travel documents (TD1 — three lines of 30, and TD2 — two lines of 36). In practical terms that includes effectively every modern passport issued by United Nations member states and most special travel documents such as refugee travel papers and emergency passports.

Over 200 countries and territories are covered. Older non-machine-readable passports issued before the ICAO 9303 mandate (pre-2010 in many jurisdictions, earlier in some) are not supported because the MRZ does not exist on those documents. If you need a country or document type that we do not currently extract well, the fastest path is to send us a few sample images — adding new visual layouts typically takes one to two weeks.

Accuracy depends on the input. On scanner-quality images of an undamaged passport, the MRZ extracts cleanly because the OCR-A font is designed to be machine-read and the engine validates against check digits — this is the most reliable signal the document offers. Visual fields such as place of birth and place of issue are extracted from the printed VIZ above the MRZ and tend to be a few percentage points lower because the fonts and layouts vary by issuing country.

On mobile photos, the most common failure modes are glare on the laminated photo page, motion blur, and the data page being cropped at an angle. The engine pre-processes for all three (deskew, glare removal, page detection), so a guided capture flow — where you prompt the user to align the passport inside an on-screen frame and tap to capture — recovers most cases without a retry. We don't publish a single percentage figure because numbers without a measurement methodology mean very little; we're happy to share a benchmark for your image distribution.

Yes — passport OCR is one of the standard building blocks of an eKYC pipeline, and the API is designed to slot in as the data-extraction step. The structured JSON output makes it straightforward to feed downstream services: PEP and sanctions screening (which need a normalised name, date of birth and nationality), age verification (date of birth), document-expiry checks (expiry date) and watch-list matching.

For compliance-grade flows you typically pair passport OCR with two additional layers. First, document-authenticity signals — the MRZ check-digit validation in our response is one such signal, and pairing it with NFC chip reading on the user's phone (for ePassports) raises the bar significantly. Second, a selfie liveness or face-match step so you bind the document to the person presenting it. The OCR API is the data layer; the authenticity and liveness layers are policy decisions you own.

The API is a single REST endpoint accepting multipart/form-data, so any language with an HTTP client works. Our public documentation includes copy-paste examples for cURL, Python (requests), Node.js (fetch + FormData), PHP (cURL), Java (OkHttp) and Ruby (Net::HTTP). If your stack is something else — Go, Rust, C#, Elixir, anything that speaks HTTP — the call signature is exactly the same.

For mobile, the recommended pattern is to capture the passport image client-side (iOS PHPickerViewController, Android CameraX, or React Native vision-camera) and POST it directly to the API from your mobile backend, rather than embedding the API key in the app. We also publish OpenAPI / Postman collections so you can generate a typed client in your language of choice.

Passport images are processed in-memory to produce the OCR result. We do not require you to grant us long-term storage rights to do extraction. By default, raw image bytes are not retained after the response is returned; only request metadata (timestamps, account ID, document type, success/failure status) is logged for billing and abuse prevention.

If you want stricter handling — for example, no derivative storage at all, customer-controlled keys, or a specific processing region — that is configurable on enterprise plans. For compliance-regulated workloads we publish a Data Processing Addendum on request and can scope deployments to specific regions. Please contact sales if you have specific data-residency requirements before integrating; it is much easier to set up correctly the first time than to migrate later.

Pricing is per successful extraction, with a free trial that includes 100 calls so you can run an integration test against your real images before committing. Beyond the trial, plans move from pay-as-you-go (best for prototyping and low volume) to volume-based monthly bundles (best for steady production traffic) to negotiated enterprise rates for high-volume or contractual commitments.

The pricing is identical across passport, ID-card and driver-licence endpoints, so you can mix document types without surprises. There are no per-field surcharges and no additional fees for MRZ parsing — every passport extraction includes the full ten-field response. See the pricing page for current per-call rates and bundle thresholds.

Mindee and Nanonets ship general-purpose document AI platforms with a passport endpoint among many. They are good products, especially if your team also wants to extract receipts, invoices or arbitrary forms in the same place. AWS Textract is a generic OCR primitive — it returns text blocks and tables, but you are responsible for writing the passport-specific parsing logic, including MRZ check-digit validation, on top.

PicToText is narrower: passports, ID cards and driver licences are the product, not a feature. The benefit is that the response shape is opinionated and stable (no toggling 30 optional fields), and the underlying models are tuned specifically for travel and identity documents. The tradeoff is that we are not the right pick if you also need to OCR arbitrary business documents in the same place. Most teams who choose us are running an identity or KYC flow and want a focused vendor with the same interface across the three document types.

End-to-end latency from receiving the multipart payload to returning the JSON response is typically in the low single-digit seconds on a clear image, dominated by image decoding and the OCR model inference. Latency scales with input image resolution: a 4-megapixel mobile capture costs more wall-clock time than a 1080p-equivalent screenshot.

For latency-sensitive flows (real-time hotel check-in, in-app onboarding) the most effective lever you control is client-side preprocessing — capture at a reasonable resolution (the data page only needs about 1200px on the long side for the MRZ to be readable), strip EXIF metadata, and re-encode as JPEG quality ~85 before uploading. That cuts upload time on mobile networks, which is usually a bigger contributor than server-side processing.