How to Choose a Passport OCR API: 9 Evaluation Criteria

Every passport OCR API promises the same thing: send a photo, get the data. The differences appear in production, and by then you've already migrated.

Here are the criteria to evaluate them on and — more importantly — how to test each one before committing. We don't compare named vendors: prices and capabilities change every quarter, a competitor table ages badly, and it's usually unfair. We'd rather give you the method to run your own evaluation with today's data.

1. Does it validate the MRZ check digits?

The most important criterion, and the least often asked about.

A passport carries four check digits that let you arithmetically confirm the number and dates were read correctly. An API that doesn't validate them is discarding the best quality signal the document contains.

How to test: send a passport and see whether the response includes both complete MRZ lines. If it doesn't return them, you can't verify anything yourself — and the vendor probably isn't either.

2. What does it do when it can't read?

There are two possible behaviours, and the difference is enormous:

• Fail explicitly — "I couldn't read these fields."
• Return its best guess — data with the right shape and the wrong contents.

The second is far worse than it sounds, because the error is invisible: a passport number with one character changed passes any format validation and lands intact in your database.

How to test: deliberately send a bad photo — blurry, glare across the MRZ, foot cropped off. If it returns complete, confident data, be suspicious. If it returns an error identifying the unreadable fields, good sign.

3. Does it charge for failures?

A direct consequence of the last point. If a vendor charges for a failed extraction, it has a financial incentive to always return something.

How to test: check what happens to your balance after a failure. In our case, a 422 LOW_IMAGE_QUALITY refunds the token: an unreadable image costs nothing.

4. How much data does it retain?

A passport is among the most sensitive personal data you'll ever move. Ask explicitly:

• Is the image stored? For how long?
• Is the extracted data stored?
• Is any of it used to train models?
• What jurisdiction are the servers in?

How to test: get it in the contract or the privacy policy, not in an email. We don't retain the data from a successful extraction: it's processed, returned, and not kept.

5. What formats and sizes does it accept?

This looks like a detail and decides whole integrations. HEIC in particular: it's what an iPhone produces by default. An API that won't take it forces you to convert client-side, with everything that entails.

How to test: send an unconverted HEIC, and an 8 MB file. Real limits surface fast.

6. How is the image submitted?

Multipart, base64, URL, raw binary. The more options, the less glue code. If your images already live in S3, being able to send a URL saves downloading them just to re-upload.

7. Are the errors manageable in code?

Look for stable, documented error codes, not just prose messages. Your retry logic needs to distinguish "retry in 2 seconds" from "this image is never going to improve".

How to test: ask for the list of codes. If the answer is "we return an error message", your error handling will end up comparing strings — which will break the day someone rewrites a message.

8. What's the real pricing model?

Compare on your actual volume, not on the list price:

• Monthly minimum, or pay-as-you-go?
• Do credits expire?
• Are failures billed? (see criterion 3)
• Do you have to talk to sales to start?

That last one is a practical filter: if you can't try the service without a sales call, you can't evaluate it against your own documents before deciding.

9. Can you test it today, with your documents?

The decisive criterion. Everything above depends on being able to run it.

Look for: a trial with no card, public documentation with runnable examples, and ideally a demo that works without signup.

An evaluation method you can run in an afternoon

1. Gather 20 real images from your own workflow, bad ones included. Evaluating with studio photos alone gives you an impression that won't survive production.
2. Add three deliberate edge cases: one with glare on the MRZ, one with the foot cropped, one low-resolution.
3. Send all 23 to each candidate and record: correct fields, honest failures, and — the one that really matters — incorrect data returned confidently.
4. Verify the returned MRZ digits yourself. The algorithm fits in ten lines and is in ICAO 9303 check digits.
5. Cost out the failures under each pricing model.

The metric that decides isn't the hit rate, it's:

Of the cases the system couldn't read correctly, in how many did it say so?

A vendor that gets 95% right and flags the remaining 5% is operationally far better than one that gets 97% right and hands back the remaining 3% as though it were correct. The first lets you build an exception workflow; the second puts silent errors in your records.

Test us with this method

You don't have to take our word for it: the free demo processes a passport with no signup and no card, and creating an account gives you 20 extractions to run the full evaluation against your own documents. Our MRZ validator is free and lets you independently verify any MRZ we return.

The documentation lists every error code, and How to integrate a passport OCR API shows how to handle each in code.