AAMVA & PDF417: How US Drivers License OCR Works | PicToText

If you're shipping KYC for US users in 2026, the document you'll see ten times more often than a passport is a driver's license. The IRS, banks, crypto exchanges, gig-economy platforms, and most state-licensed services all default to the DL as proof of identity. So if your verification flow has to work in the US, it has to be excellent at reading driver's licenses — and that means understanding the AAMVA standard and its workhorse data structure, the PDF417 barcode on the back of the card.

This guide walks through how a modern OCR API turns a phone photo of a US driver's license into clean, structured JSON. We'll cover the three data layers on the card, what AAMVA actually specifies, how PDF417 fields are encoded, where state-by-state variation creeps in, and what's about to change with mobile driver's licenses (mDLs).

Three data layers, not one

A US driver's license is not one document — it's three overlapping representations of the same identity, printed on the same piece of polycarbonate:

1. The front face (human-readable) — name, DOB, address, photo, signature, expiration, restrictions, organ donor status. This is what an officer or a bouncer reads.
2. The back PDF417 barcode (machine-readable) — every front-side field, plus issuing authority data, encoded as a high-density 2D barcode roughly 3 inches wide.
3. The magnetic stripe (legacy, optional) — still present on some state issuances, mostly deprecated in favor of the barcode.

For OCR, layers 1 and 2 matter. A serious verification pipeline reads both and cross-checks them — it's one of the cheapest, most effective anti-tampering signals available, because a forger has to defeat two encodings consistently to pass.

If you've read our piece on MRZ and ICAO 9303 for passports, you'll notice a deliberate contrast: passports compress identity into a fixed-width text zone you can OCR directly. US driver's licenses do the opposite — they push the structured data into a barcode and leave the front face for humans. Different problem, different toolkit.

What AAMVA actually defines

AAMVA — the American Association of Motor Vehicle Administrators — publishes the DL/ID Card Design Standard, currently revision 2020-2024 across deploying states. It doesn't dictate visual design (states are free to brand their cards), but it strictly specifies:

• Field semantics — what a "given name" is, how truncation works for long names, how addresses are split.
• Element identifiers — the three-letter codes (DAA, DAC, DAG, etc.) that label each field inside the barcode.
• Encoding — character sets, date formats (MMDDCCYY), document discriminator structure.
• Issuer identification — the IIN (Issuer Identification Number), a 6-digit code that uniquely identifies the issuing jurisdiction.

The point of the standard is that any reader — police scanner, bar's ID checker, KYC API — can parse a Wyoming license with the same code path as a Florida license. In practice, that's true for ~95% of fields. The remaining 5% is where production systems break, and we'll get to that.

PDF417 barcode anatomy

The PDF417 barcode is a stack of rows, each encoding bytes through a pattern of bars and spaces. After decoding the raw bytes, you get an AAMVA-formatted text payload that looks roughly like this:

@\n\x1e\rANSI 636014090002DL00410288ZC03290024DLDAQD12345678
DCSSAMPLE
DACJOHN
DADQUINCY
DBD08242023
DBB05151985
DBA05152030
DBC1
DAYBRO
DAU069 in
DAGSAMPLE ADDRESS
DAILOS ANGELES
DAJCA
DAK900010000
DCFNONE
DCGUSA
DCK1234567890
DDB08242018

A few things to notice:

• The header (@\n\x1e\rANSI ...) declares it's an AAMVA-compliant ANSI payload and gives the IIN (636014 here = California).
• Each subsequent line is a subfile containing an element identifier (three letters) followed by its value.
• There's no length prefix — fields are line-delimited by \n.

Here's a working subset of the element identifiers you'll see most often:

Code	Field	Notes
DAQ	License number	Format varies wildly by state
DCS	Family name	May be truncated to 40 chars
DAC	First (given) name
DAD	Middle name(s)	Optional
DBA	Expiration date	MMDDCCYY
DBB	Date of birth	MMDDCCYY
DBC	Sex	1 = male, 2 = female, 9 = not specified
DBD	Issue date	MMDDCCYY
DAY	Eye color	3-letter code (BRO, BLU, HAZ, ...)
DAU	Height	Inches with in suffix
DAG	Street address line 1
DAI	City
DAJ	State (issuing)	2-letter
DAK	ZIP / postal code	Often padded with zeros
DCF	Document discriminator	Anti-counterfeit token
DCG	Country	USA
DCK	Inventory control number
DDB	Card revision date

Modern AAMVA revisions add fields for organ donor status, weight, race, REAL ID compliance, and endorsement/restriction codes. A good parser ignores unknown identifiers gracefully — states roll out new ones on their own schedule.

Why you still need front-side OCR

If the barcode contains every field, why OCR the front at all? Three reasons:

1. Tamper detection. If the front-side text doesn't match the barcode, you have a strong signal that the card was physically altered. A forger who reprints the front but can't regenerate a valid PDF417 (which requires the AAMVA codec and proper IIN) gets caught here.
2. Photo and signature extraction. The barcode doesn't contain biometric data. Face matching against the front-side photo is the single most important step in remote KYC; without it, a stolen-but-valid license is enough to onboard.
3. Damage and partial scans. Worn cards, glare on the back, or a user who only photographs the front happen constantly. Front-side OCR is the fallback that keeps your funnel from breaking.

This dual-channel approach — barcode-first, OCR-as-cross-check — is exactly the foundational vs functional distinction in action. The DL is foundational (issued by government, used for binding identity), so the bar for validation is higher than for a utility bill or a club membership.

State variations that break naive parsers

The AAMVA standard is consistent on field names but lenient on field content. Production systems trip on:

• License number format. California is 1 letter + 7 digits. Florida is 1 letter + 12 digits. Wisconsin is 14 alphanumerics. Don't validate against a single regex.
• Truncation. AAMVA allows family names up to 40 characters but most card surfaces only render ~25. The barcode contains the full string; the front face may show BANKS-WASHINGTON-LONGNAME cut to BANKS-WASHINGTON-LO. Compare the truncated form, not exact equality.
• Vertical "under-21" layouts. Most states issue a vertical orientation card for minors. Your OCR pipeline must handle 90°-rotated input or it will read everything as garbage.
• REAL ID indicators. Look for a star (often gold or black) in the upper-right corner. The barcode includes a DDA or DDD REAL ID compliance flag — confirm it matches the visual marker.
• Temporary paper licenses. Issued when a renewal is in transit. Usually have a barcode but no photo. Many state APIs flag these as "interim" — your KYC policy should decide whether to accept them.
• Lifetime expirations. Some states issue "no expiration" licenses to certain age groups. DBA may be set to a sentinel date like 12312099. Don't fail validation on these.

What's coming: mobile driver's licenses (mDL)

The next big shift is the ISO/IEC 18013-5 mobile driver's license standard. About a dozen US states have issued mDLs that live in Apple Wallet or Google Wallet, presented over Bluetooth/NFC with selective disclosure (you can prove "over 21" without revealing your DOB).

For OCR-based KYC, mDL doesn't replace the physical card overnight — adoption is slow and cross-state acceptance is uneven — but you'll start seeing more screenshots of mDLs in onboarding flows. A robust pipeline should detect and reject screenshots as a separate signal class rather than try to OCR them.

A practical workflow

If you're building a US KYC flow from scratch, here's the layout that consistently works:

1. Ask the user to photograph both sides. Front + back, not just one.
2. Parse the PDF417 barcode first. It's deterministic, fast, and contains everything you need for identity binding.
3. OCR the front face. Extract name, DOB, expiration, address.
4. Cross-validate. Reject if barcode and front disagree on the last name, DOB, or expiration. Tolerate minor differences in casing, truncation, and address formatting.
5. Run face match between the front-side photo and a live selfie. This is non-negotiable for any flow with money or regulated services.
6. Verify REAL ID compliance if your downstream service requires it (federal facility access, domestic flights after the federal deadline).
7. Log the document discriminator (DCF) and IIN — they let you trace back to the issuing state and detect duplicate submissions.

PicToText's Drivers License OCR API implements this workflow as a single endpoint: send the front and back images, get back a structured JSON object with the parsed barcode, OCR'd front-side fields, cross-validation flags, and a face crop ready for downstream matching. It's the same pipeline our customers use for end-to-end KYC flows handling tens of thousands of US verifications a day.

Getting started

The full field reference, error codes, and example responses live in our Quickstart guide. You can test with a real US license image in under five minutes. Drop the image in, get back parsed fields, and you'll see immediately whether the barcode and front face agree.

The AAMVA standard isn't going anywhere — states would have to coordinate a once-in-a-generation redesign to deprecate PDF417. So the investment in getting US driver's license OCR right pays off for years, not quarters. Get the barcode + OCR cross-check working once, and the same architecture handles Texas, California, Florida, and the other 47 jurisdictions without per-state branching.