The US Passport: Fields, Versions and How to Read It
A guide to the US passport data page: what fields it carries, how the name is encoded in the MRZ, what the passport card is and why its MRZ is a different format, and what changes with the electronic passport.
The US passport follows ICAO 9303 like any other, so its MRZ is structurally identical to a German or Japanese one. But it has particularities — in the passport card, in the name encoding, in the endorsements page — that matter if you're processing American documents.
Who issues it and how long it lasts
US passports are issued by the Department of State, and appear in the MRZ under country code USA, both at positions 3-5 of line 1 (issuing country) and 11-13 of line 2 (nationality).
Adult passports are issued with 10 years of validity; passports for minors with 5. This is unusually consistent compared with countries offering several validity options, and it makes a useful consistency check: an issue-to-expiry gap that is neither 5 nor 10 years on a USA passport is worth a look.
The passport book vs. the passport card
This is the distinction that catches integrations out. The United States issues two travel documents, and they use different MRZ formats:
| Passport book | Passport card | |
|---|---|---|
| Physical form | Booklet | Credential-sized card |
| MRZ format | TD3 — 2 lines × 44 | TD1 — 3 lines × 30 |
| Valid for | International travel | Land/sea entry from specific neighbouring countries |
The consequence for your code is concrete: a reader that assumes TD3 will silently misparse a passport card. TD1 puts the name on line 3 and the document number on line 1, so TD3-shaped parsing returns the document number where you expected a surname — with no error raised, because nothing is syntactically invalid.
If your workflow accepts "a US passport" without qualification, you will eventually receive cards. Detect the format from line count and length before parsing anything; the detection function and the full layout differences are in MRZ formats: TD1, TD2 and TD3.
The data page fields
The book's data page carries, in the visual zone:
| Field | Notes |
|---|---|
| Type | P |
| Code | USA |
| Passport No. | Nine characters |
| Surname | |
| Given Names | |
| Nationality | UNITED STATES OF AMERICA |
| Date of birth | |
| Place of birth | State or country of birth |
| Sex | |
| Date of issue | |
| Date of expiration | |
| Authority | United States Department of State |
| Endorsements | On a separate page |
Plus the two MRZ lines at the foot.
Two notes for anyone integrating:
Place of birth is not a fixed vocabulary. For those born in the US it's typically a state; for naturalised citizens, the country of birth. Don't validate it against a state list.
Endorsements aren't on the data page. Anything recorded as an endorsement lives on its own page and won't appear in an extraction from the data page. If your process needs it, capture that page separately.
The personal number field is empty
MRZ positions 29-42 on line 2 are the personal number field, 14 characters. The United States doesn't use it — it arrives as filler:
G123456786USA8007050M3307054<<<<<<<<<<<<<<08
└── personal number: filler ──┘
There is no Social Security Number in a US passport MRZ, and none on the data page either. Any system expecting to derive one from a passport is built on a false premise. If you need an SSN, you must collect it separately — it is not on the document.
Name encoding
ICAO 9303 splits the name into a primary identifier (surname) and a secondary identifier (given names), separated by <<, with single < between words:
SMITH<<JOHN<ROBERT
└surname┘ └given names┘
Three cases that break naive parsing:
Hyphenated surnames. A surname like Smith-Jones is transliterated with a < where the hyphen was, making it look like two separate name words. Storing the primary block whole, rather than splitting it, avoids the problem.
Suffixes. Jr., Sr., III are handled inconsistently across issuers and may appear inside the surname block. Don't assume the last token is a given name.
Truncation. The name field is 39 characters. A long name gets cut, and the truncated form is the official MRZ data, not a misread. Cross-check against the visual zone, where the full name is printed.
And the general rule that applies to any passport: the MRZ is A-Z only, so accented characters are transliterated. If you compare an MRZ name against your database character by character, every name with a diacritic will fail. Normalize both sides:
function normalizeForComparison(name) {
return name
.normalize('NFD')
.replace(/[\u0300-\u036f]/g, '')
.toUpperCase()
.replace(/[^A-Z]/g, '')
}
normalizeForComparison("O'Brien-Müller") // "OBRIENMULLER"
Store the properly-cased, accented name from the visual zone as your business data, and use the normalized form only for matching. Addressing a customer as "Dear SMITH" because your system kept the MRZ form is an avoidable mistake.
The electronic passport
US passports have carried a contactless chip for many years — storing the data page contents and the photograph, cryptographically signed. The international e-passport symbol is printed on the cover.
What changes and what doesn't, for an OCR workflow:
- For optical reading, nothing changes. The data page and the MRZ are still there and read the same way.
- The chip is a separate matter. Reading it needs NFC hardware and a different protocol, in which the MRZ acts as the access key: without having optically read the MRZ first, the chip won't open.
So MRZ reading is the prerequisite for chip reading, not an alternative to it. And since passports issued before the chip remain valid until they expire, any system receiving US documents has to handle both generations. The MRZ is what they have in common.
What our API returns
{
"passportNumber": "G12345678",
"surname": "SMITH",
"givenNames": "JOHN ROBERT",
"nationality": "USA",
"issuingCountry": "USA",
"dateOfBirth": "05/07/1980",
"dateOfIssue": "10/03/2023",
"dateOfExpiry": "05/07/2033",
"sex": "M",
"placeOfBirth": "CALIFORNIA, U.S.A.",
"issuingAuthority": "United States Department of State",
"personalNumber": "",
"mrzLine1": "P<USASMITH<<JOHN<ROBERT<<<<<<<<<<<<<<<<<<<<<",
"mrzLine2": "G123456786USA8007050M3307054<<<<<<<<<<<<<<08"
}
Note personalNumber comes back empty — correctly so, since US passports don't populate that field. Both MRZ lines arrive complete with all four check digits verified.
Try it on a real passport
The free demo processes a passport with no signup. If you already have a transcribed MRZ, the validator recomputes its check digits for free.
For the position detail, see How to read the MRZ line by line; for the verification arithmetic, ICAO 9303 check digits.
Need to extract passport data automatically?
Try our API with 20 free extractions. Integrate in minutes, get results in seconds.
Start for free