Reading the Card Without the Barcode
Most automated checks read the back of a card, because the barcode is there and a barcode is unambiguous. But plenty of systems read the front instead, using optical character recognition to lift the printed text directly. Anywhere you have photographed a licence with a phone to open an account, something on the other end almost certainly ran OCR over that image.
This guide explains how text recognition works on a card front, which characters it reliably confuses, and why the front and the back can disagree. It complements the encoded route described in what is encoded in a licence barcode.
Why Read the Front at All
The barcode is the better data source when you can get it, so front reading exists for situations where you cannot. A phone camera pointed at a card in a user's hand captures the front naturally. A remote onboarding flow asks for a photo of the front because that is where the portrait is, and the portrait is needed for the face comparison anyway.
There is also a verification argument. Reading both sides and comparing them is a genuine check: a card whose printed name does not match its encoded name has been tampered with, and only reading both catches it. That comparison sits inside the identity flows described in how eKYC identity verification works.
How the Software Finds the Fields
What the software sees is not a picture of a card so much as a set of expected regions. Recognition on a licence is not general purpose text reading. The software knows what a licence looks like, and it uses that structure at every stage:
- Locate the card edges and correct for perspective, so a photo taken at an angle is flattened.
- Identify the design, often from the state name and layout, to know where each field should sit.
- Crop to expected field regions rather than reading the whole card as free text.
- Apply the field's expected format, so a date region is read as a date and a height region as a height.
That last step does most of the heavy lifting. Knowing a region contains a date lets the reader reject an interpretation that is not a valid date, which resolves a large share of ambiguous characters before anyone has to guess.
The Characters It Confuses
Even with format constraints, some pairs cause persistent trouble, and they are always the same ones: zero and the letter O, one and the letter I and a lowercase L, five and S, eight and B, two and Z, six and G. In a name field, where format rules cannot help, these are genuine coin flips.
Card designers know this. It is one reason licence typefaces are chosen for character distinctiveness rather than elegance, a subject covered in fonts and typography on driver licences. A well chosen face with a slashed zero and a seriffed one removes most of the ambiguity at the source.
What Ruins a Read
Most OCR failures are not clever forgeries, they are ordinary photography. Glare from a laminate across the data block wipes out characters entirely. A card held at an angle stretches glyphs beyond what the model expects. Low light produces noise that fills in the gaps in letters. A worn card with abraded print simply has less to read.
The security features themselves get in the way too. Optically variable overlays and holographic laminate are designed to interact with light, and under a phone flash they can flare across exactly the region the reader wants. That is why capture flows nag about glare and angle rather than trusting the software to cope.
Why the Barcode Still Wins
A barcode carries its own error correction, so a partially damaged symbol still decodes correctly or refuses outright. OCR has no equivalent: it returns its best guess, and a best guess can be confidently wrong. That difference matters more than raw accuracy, because a system that knows it failed is safer than one that does not.
The practical result is that serious verification reads the barcode when it can and treats front OCR as a supplement, useful for cross checking and for capturing the portrait. Where both are available, disagreement between them is the most valuable signal either one produces. The wider set of reading technologies is covered in the ID security features hub.
Frequently Asked Questions
What is OCR on an ID card?
Optical character recognition is software that reads the printed text on the front of a card from an image. It is how a phone photo of a licence turns into name and date fields without anyone typing them.
Why read the front when the barcode holds the same data?
Because the barcode is not always available. A phone photo naturally captures the front, and the portrait needed for face comparison is there. Reading both sides also allows a comparison, which catches a card whose printed data was altered.
Which characters does OCR get wrong most often?
Zero against the letter O, one against I and lowercase L, five against S, eight against B, two against Z, and six against G. Format rules resolve many of these in dates and numbers, but name fields have no such safety net.
Why does my phone keep asking me to retake the photo?
Usually glare or angle. Laminate and optically variable features reflect the flash straight back across the data block, and a tilted card distorts the glyph shapes past what the model expects.
Is front OCR as reliable as scanning the barcode?
No. A barcode carries error correction, so it either decodes correctly or fails visibly. OCR returns a best guess and can be confidently wrong, which is why careful systems treat it as a cross check rather than the primary source.
Does OCR check whether the card is genuine?
Not by itself. It reads text, and text can be printed by anyone. Authenticity comes from the physical features and, where available, from comparing the printed data against the encoded data.