Free Driver's License Barcode Decoder
The barcode on the back of a driver's licence is unencrypted plain text. Drop in a photo of it, or paste the scanned text, to see every field it hands over — name, date of birth, address, document number and the rest. Nothing leaves your browser.
Nothing you paste leaves your device. This decoder is plain JavaScript running in your own browser. There is no upload, no server call, no logging and no storage. That matters more here than on any other tool on this site: the barcode on an identity document carries your full legal name, date of birth, home address and document number in plain text. Decode your own card, not anyone else's.
Have a photo of the back of your licence?
Choose it, drop it here, or paste it with Ctrl+V / ⌘V. The PDF417 is read on your device and never uploaded. Photograph it flat, in good light, filling most of the frame.
Scan the PDF417 barcode on the back of the card with any scanner app, then paste the raw text here. It starts with @ and contains ANSI or AAMVA a few characters later. If the line breaks came through as a literal \n, paste it anyway — that is handled.
Try a sample card (every value is invented)
How the Barcode Is Structured
The PDF417 barcode on the back of a North American driver's licence or state ID card is defined by the AAMVA DL/ID Card Design Standard. It is plain text — not encrypted, not a key into a database, not a token. Anything that can read a PDF417 symbol can read every field, and the standard that says what the fields mean is published.
The string is built in three parts:
- A header. A @ compliance indicator, three separator characters, the file type (ANSI on current cards, AAMVA on some older ones), then a six-digit Issuer Identification Number, the AAMVA version number, the jurisdiction's own version number, and how many subfiles follow.
- One designator per subfile — two letters naming the subfile (DL for a driver's licence, ID for an identity card, Z plus a letter for a jurisdiction's private data), then a four-digit byte offset and a four-digit length.
- The subfiles themselves. Each is a list of fields, one per line, where the first three characters are the element identifier and everything after them is the value. DCS is the family name, DBB the date of birth, DAG the street address, and so on.
Because the element identifiers are self-describing, the decoder above reads them directly rather than trusting the byte offsets in the header. That is deliberate: offsets are among the most commonly wrong values on real cards, and a decoder that trusts them fails on documents that scan perfectly well everywhere else. Where the offset disagrees with what is actually at that position, you get a warning rather than an error.
Three Things That Make a Decode Go Wrong
1. The date order depends on the country
Dates are eight digits, but the field order is not the same on both sides of the border: MMDDCCYY in the United States and CCYYMMDD in Canada. The same eight digits are therefore two different candidate dates. A decoder that assumes one order silently reports the wrong birthday on cards from the other country.
The good news is that no guessing is needed. A four-digit year in any plausible range begins 18 through 22, and a month never exceeds 12, so at most one of the two readings can be a real date. That holds for every valid date from 1850 to 2200 — checked exhaustively, not assumed. The decoder uses the issuing country when the card states it and falls back to whichever ordering produces a real date, and it tells you which one it used.
2. The element identifiers changed between versions
The first name is DAC on current cards, but it was DCT in the 2003 and 2005 revisions. The family name was DAB in the original 2000 standard and has been DCS ever since. The licence number was DBJ and is now DAQ. A card issued for eight years and renewed slowly means all of these are still in circulation, so the decoder reads the version number from the header first and labels the fields accordingly.
3. The header is one digit group shorter on the oldest cards
The jurisdiction version number was added in the 2003 revision. On a version 01 card the header carries ten digits after the file type rather than twelve, so anything that assumes twelve reads the subfile count out of the wrong two characters and then fails to find any fields at all.
A Worked Example, Traced by Hand
Here is a short, entirely fictional card — 93 characters, one subfile, seven fields. The three invisible separator characters after the @ are shown as ·:
@···ANSI 999999100101DL00310062DLDAQD1234567
DCSSAMPLE
DACJANE
DBB03091991
DBC2
DAJZZ
DCGUSA- 999999 — the Issuer Identification Number. A real card carries a number registered to its issuing authority.
- 10 — the AAMVA version number, which is the 2016 revision of the standard.
- 01 — the jurisdiction's own version number, meaningful only to that jurisdiction.
- 01 — one subfile follows.
- DL0031 0062 — that subfile is a driver's licence record, starting at byte 31 and running for 62 bytes. Counting from the @ at byte 0, byte 31 is indeed where DLDAQ begins, and 93 − 31 = 62. The header is telling the truth, which on a real card is worth checking rather than assuming.
- DBB03091991 — the date of birth. The card says DCGUSA, so this is MMDDCCYY: 9 March 1991. Had the same digits appeared on a Canadian card they would have been read as CCYYMMDD, and 0309 is not a valid year in any plausible range, so the decode would have failed rather than quietly returning a wrong date.
Seven fields, and five of them are personal: name, given name, date of birth, sex and licence number. A real card carries three to four times as many.
When You Would Use This
Seeing what a bar, clinic or rental desk actually received
The most common reason people find this page. An age check needs one bit of information — whether you are over a threshold — but a barcode scan hands over everything on the card at once. Decoding your own is the only way to see the difference concretely, and the decoder counts the fields for you.
Checking a card against its own printed face
The printed front and the encoded barcode are produced by separate processes and can disagree — a misspelled name, a truncated surname, a stale address after a move. If a card is being rejected by readers, the barcode is where the discrepancy shows up.
Understanding what a breach exposed
When an ID-verification provider loses its records, what leaks is not "a scan of a licence" in the abstract but a specific list of fields. Decoding your own card shows you which ones, which is a better basis for deciding what to do than a press release.
Developers working on document capture
A field-by-field reference decode with the element identifiers shown, without wiring up an SDK. The version-specific identifier changes and the date-order rule are the two things integrations usually get wrong, and both are called out explicitly here.
What This Tool Does Not Tell You
- Whether the card is genuine. Nothing in the barcode is signed or verifiable. The data is plain text, so a well-formed barcode proves only that someone wrote well-formed text. Real authentication relies on the physical security features of the card and, increasingly, on a cryptographically signed mobile credential — not on the barcode.
- Which jurisdiction the Issuer Identification Number belongs to. AAMVA maintains that register and this tool does not reproduce it, so the IIN is reported as the digits it is. The card's own jurisdiction field (DAJ) is usually the better answer anyway, and the decoder shows it.
- What a jurisdiction's private subfile means. Fields in a Z subfile are defined by the issuing authority, not by the standard, and are often undocumented. They are listed verbatim and labelled as jurisdiction-defined rather than guessed at.
- Whether your state permits a business to keep any of this. That depends on where you are and, in several states, on why the scan was taken. The guide linked below covers what the rules generally look like, but a statute governs, not a web page.
Related Tools & Guides
- What's in the barcode on your driver's license — the full explainer behind this tool: every field, who scans it, and what they are allowed to keep.
- Boarding pass barcode decoder — the equivalent decoder for the other unencrypted document most people carry.
- What's in your boarding pass barcode — the same plain-text problem in travel documents.
- Types of barcodes explained — where PDF417 sits among the formats you meet day to day, and why it was chosen for identity documents.
- GS1 barcode decoder — the equivalent decoder for retail, logistics and pharmacy barcodes.
Frequently Asked Questions
What information is in the barcode on a driver's license?
Typically your full legal name, date of birth, sex, height, eye colour, full home address, the document number, the issue and expiry dates, your licence class and any restrictions or endorsements — plus administrative fields such as a document discriminator and, on many cards, organ-donor and veteran indicators. The AAMVA standard marks about twenty of these as mandatory and jurisdictions add their own. In short, it carries everything printed on the face of the card and usually a little more.
Is the barcode on my license encrypted?
No. It is plain text in a published format. That surprises people, but it is deliberate: the barcode exists so that any compliant reader — a police car, a hospital, a car rental desk — can read a card from any state without a shared key or a network lookup. The consequence is that anyone who can read a PDF417 symbol can read every field, and nothing in the barcode proves the card is genuine.
Can a bar read my address when it scans my ID for age?
Technically, yes. A barcode scan returns the whole record, not the one fact being checked, so the address, document number and date of birth all arrive together. Whether the business may keep any of it is a separate question that depends on your state, and several states restrict retention specifically for age checks. Decoding your own card is the clearest way to see what was transferred.
Why does the decoder say my date of birth is wrong?
Almost always the country. AAMVA dates are eight digits, and the field order is MMDDCCYY in the United States but CCYYMMDD in Canada, so the same digits describe two different dates. This decoder uses the card's own issuing-country field when it is present and otherwise picks the only ordering that yields a real date — a four-digit year cannot also be a month, so exactly one reading works. It tells you which ordering it used.
Why did my older license fail to decode in other tools?
Two reasons, both version-related. The element identifiers changed between revisions of the standard: the first name was DCT in the 2003 and 2005 versions and is DAC now, the family name was DAB in the original 2000 version and is DCS now, and the licence number moved from DBJ to DAQ. Separately, the jurisdiction version number was only added in 2003, so a version 01 header is two digits shorter and a parser expecting the longer form reads the subfile count from the wrong place.
The tool warned me about a wrong offset. Is my card broken?
Probably not. The header declares where each subfile starts and how long it is, and those numbers are wrong on a great many real cards while the cards themselves scan perfectly. This decoder reads the three-letter element identifiers directly instead of trusting the offsets, so a bad offset produces a note rather than a failure. It is worth knowing about if you are building an integration, and safe to ignore otherwise.
Can this tool tell me whether an ID is fake?
No, and no barcode decoder can. The data is unsigned plain text, so a well-formed barcode only proves that someone wrote well-formed text. Genuine verification depends on the physical security features of the card, on a check against the issuing authority, or on a cryptographically signed mobile credential. Treating a clean barcode decode as proof of authenticity is the mistake this tool exists to help you avoid, not to help you make.
What are the ZA to ZZ fields?
Those are jurisdiction-defined subfiles. The standard reserves a Z followed by any letter for data an issuing authority wants to carry for its own purposes, and it does not say what the fields inside mean. They commonly hold internal audit values, card-stock references or local flags. This decoder lists them verbatim and labels them as undocumented rather than guessing.
Does anything I paste here get uploaded?
No. The decode is plain JavaScript running in your browser, with no network request, no logging, no analytics on the input and no storage — reload the page and it is gone. That matters more here than on most tools, because this particular string is your legal name, date of birth and home address in one place. Decode your own card, not somebody else’s.
You Need a Scanner to Read the Barcode First
This decoder works on the text, and the text comes from scanning the PDF417 symbol on the back of the card. Scan & Generate reads PDF417 along with QR, Aztec, Data Matrix, Code 128, EAN-13 and seven other formats — 13 in all — and shows you the raw contents as text rather than acting on them. Scan your own card, then paste the result here to see exactly what a reader receives.