The driver’s license changes at the state line.

A passport reading has a built-in second opinion. The machine readable zone at the bottom of the data page repeats the key fields in a fixed format, with check digits, so an extraction can test itself before anyone looks at it. That check is covered in the MRZ article, along with its limits.

A US driver’s license usually offers no such zone on the front. What it offers is a card designed by one of more than fifty issuing jurisdictions, each with its own layout, labels, fonts, background patterns and redesign schedule. Reading it well is less about OCR accuracy on a single image and more about knowing what every card has to say, where a given state says it, and what to do when a field cannot be read with confidence.

The same facts, printed fifty ways

For cards that federal agencies accept for official purposes, the content of the front is not a matter of state taste. The REAL ID regulation, 6 CFR 37.17, lists what the surface must carry:

• Identity — full legal name, date of birth, sex as determined by the state, and a full facial photograph.
• The card itself — a unique license or card number that cannot be the Social Security number, the date of transaction, the expiration date, and the state or territory of issuance.
• Residence — the address of principal residence, with defined exceptions for an alternative address.
• Holder and security — the holder’s signature, physical security features, and a DHS-approved marking that shows the card’s level of compliance.

The same section requires the name, date of birth, sex, card number, issue date, expiration date and address on the face to be printed in Latin alphanumeric characters. That is useful for extraction, and it is close to the end of what is uniform. Where the number sits, whether the label says “EXP” or “Expires”, whether dates are printed with slashes or dashes, how the name is split across lines, and which side carries the endorsements are all state design choices.

So the extraction schema should be built on the regulation’s list of facts, and the layout knowledge should sit underneath it, per state and per card design. A field called expiration_date means the same thing for every card; how it is found does not.

No check digit, so the checks come from elsewhere

On a passport, a misread digit in the document number usually breaks the check digit, and the error announces itself. On the front of a license, a misread 8 that became a 3 produces a perfectly plausible number. Nothing on the card disagrees with it.

That changes where the controls live. Without an internal check, an extraction has three sources of independent evidence:

• Field logic on the card — the date of birth comes before the date of transaction, which comes before the expiration date, and the expiration date is either in the future or the card is expired.
• Known formats — each state’s license numbers follow its own patterns of length and character classes, which can be maintained as data and tested against samples. A number that fits no pattern for the issuing state is a reading problem or a document problem, and either way it needs a person.
• What the applicant already told you — the name and date of birth typed into the onboarding form are a comparison, not a correction. When they differ, the difference is the finding.

None of these is as strong as a check digit, and none should be dressed up as one. Each result should be recorded as what it is: a consistency check passed, a format matched, a value compared.

Example: one license, six fields, two sent to review

Consider a fictional license captured during onboarding. The front is photographed on a desk with some glare across the upper right corner, where this state prints the expiration date. The applicant’s form gives the name as Jordan Alexander Montgomery Whitfield-Castellanos, 49 characters with spaces, born March 4, 1991.

Four fields are settled. The two that are not are exactly the ones where a confident guess would do the most damage. A guessed expiration year can accept an expired card; a guessed card type can record a limited-term license as a standard one. The right output is not a best reading. It is a reading with its uncertainty attached and a request for a better photo, which on a phone takes the applicant seconds.

Card type is a field, and absence is not evidence

The card type matters as much as the name, and it is easy to get wrong by omission. The regulation provides for at least three situations the front of the card has to reveal:

• Compliance marking — 37.17(n) requires a DHS-approved security marking reflecting the card’s level of compliance.
• Not for federal purposes — under 37.71, a compliant state that also issues non-compliant cards must state on their face that the card is not acceptable for official purposes, and give them a distinct design or color indicator.
• Temporary or limited-term — under 37.21, these cards go only to people with temporary lawful status, must say so on the face, and cannot run past the end of the authorized stay, or more than one year when that stay has no end date.

An extraction that reports “no limited-term wording found” has not shown that the card is a standard license. It has shown that it did not see the wording. On a sharp, complete image of a known design, that may be strong evidence. On a cropped, glared or unfamiliar card, it is no evidence at all. Record the card type with its own confidence, and let an unreadable marking area produce “not established” rather than a default.

The same applies to expiry on a limited-term card. Its expiration date may reflect a lawful-status end date rather than the state’s usual renewal cycle. A short remaining validity is a fact for the business rule to weigh, not an anomaly for the extraction to correct.

Name and address follow their own rules

Two fields have rules written into the regulation that a naive comparison will trip over.

The name field must hold at least 39 characters in total, and longer names are truncated following the ICAO 9303 standard. A long hyphenated or multi-part name can therefore appear on the card shorter than on the application, with no error anywhere. The comparison should apply the truncation rule and record that it did, the same way the MRZ article recommends recording a transliteration. “Matched after truncation” tells a reviewer why two different strings were accepted as one name.

The address may not be the place the holder lives. Section 37.17(f) allows an alternative address for people in state address confidentiality programs, people whose address is suppressed by law or court order, and others where state rules permit it. An address mismatch with a utility bill is worth a question in some workflows. It is not, by itself, a sign that the license is false, and a rule that treats it as one will fall hardest on people the exception was written to protect.

The back of the card

The machine readable technology on a compliant card is on the back. Section 37.19 specifies a PDF417 barcode with a minimum set of data elements, including the name, date of birth, sex, address, card number, expiration date, issuing state, an inventory control number and a card design revision date. Where a workflow decodes that barcode, comparing it with the printed front is a meaningful check, closer in spirit to the MRZ comparison than anything on the front alone.

This article is about reading the visible front of the card, and Cogneris does not claim here to decode the barcode. If your process depends on that comparison, specify it explicitly in the integration and test it on your own samples rather than assuming it from a general description of ID extraction.

Layouts change, and old cards stay valid

States redesign their cards, and a redesign does not recall the cards already issued. A licensed driver can carry a card from an older design for years after a new one appears. The card design revision date that 37.19 puts into the barcode exists precisely because the visible format changes.

For extraction, that means layout knowledge is a versioned set per state, not one template per state, and the design version that was matched belongs in the result. When a new design appears, the first readings should be reviewed until the layout has been validated on real samples. Build and test that set with specimen images that states and vendors publish, or with synthetic cards; real customer licenses belong in production, under your retention rules, not in a test folder.

What the reading should hand over

The output of a driver’s license extraction is the input to decisions made elsewhere: whether to onboard, whether to rent the car, whether a face match is worth running. It should carry, for each field, the value, the confidence, the location on the image, and the check that was applied with its result. It should carry the issuing state, the design version matched, and the card type with its own confidence. And it should say which fields were sent to review and why.

The face on the card is a separate question. Comparing it with a selfie is a scored decision with its own threshold, discussed in the face match article, and it should never be implied by the success of the text extraction.

Where the software stops

Cogneris extracts the fields defined for your tenant from identity documents and can return confidence and source references, which is what the review routes above depend on. Coverage of a given state, card design and field has to be validated against representative samples before launch; it is not established by a general claim about licenses. Whether a card is genuine, whether an expired or limited-term card is acceptable, and whether the person in front of the camera is the person on the card are decisions for your identity verification process and your policy.

The license, name and dates in the example are fictional. This article describes document handling; it is not legal or compliance advice.