AAMVA Barcode Validator
SecurityValidate the AAMVA 2D barcode data from a US/Canada driver's licence. Checks the PDF417 barcode header, subfile structure, and data elements.
Reviewed by the thecalcu.com team · Last updated July 5, 2026
What is a AAMVA?
The AAMVA Barcode Validator checks the raw data string encoded in the PDF417 2D barcode found on the back of every US state and Canadian provincial driver's licence and government-issued ID card. AAMVA, the American Association of Motor Vehicle Administrators, publishes the specification that all North American jurisdictions follow when encoding identity data into these barcodes, and this validator confirms that a given data string conforms to that specification.
Every US driver's licence issued since the early 2000s carries a PDF417 barcode that stores the cardholder's full name, date of birth, address, licence number, eye colour, height, weight, and jurisdiction metadata in a compact, machine-readable format. When a bartender scans your licence, when a TSA officer checks your ID, or when a rental car company verifies your age, their system is decoding this exact AAMVA data structure.
The validator accepts the raw string output from a PDF417 scanner and checks the compliance indicator, file type indicator (ANSI), issuer identification number, AAMVA version number, jurisdiction version, subfile designator (DL or ID), and the presence of mandatory data elements defined by the AAMVA DL/ID Card Design Standard. Validation runs entirely in your browser, no data leaves your device.
This is a format and structure validator, not a live government lookup. Passing validation means the barcode data is correctly formed; it does not confirm the licence is genuine, currently active, or belongs to the named person. If you are also checking the licence number format for a specific US state, the US Driver's License Validator covers pattern matching for all 50 states. For validating FCC wireless device authorisation IDs, see the FCC ID Validator.
Why Use an AAMVA Barcode Validator?
Developers building ID verification flows, age verification systems, kiosk software, or access control integrations often need to validate a scanned barcode before attempting to parse its data fields. Passing a malformed or truncated AAMVA string to a parser typically produces cryptic errors or silently returns wrong values. This validator lets you confirm structural validity upfront.
Common pain points it solves:
- Integration testing: verify that a scanning SDK or hardware scanner is outputting complete, well-formed AAMVA strings before your parsing logic runs against them
- Debugging scan failures: quickly determine whether a failed scan produced a truncated string, an incorrect format, or a non-AAMVA document
- Data quality checks: confirm that barcode strings stored in a database from a prior ingestion step are structurally valid before bulk processing
- Staff training: give frontline staff a reference tool to diagnose whether a problematic ID scan is a scanner issue or a card defect
The validator is particularly useful for compliance-adjacent workflows where you need a paper trail confirming that barcode data was structurally verified before it was acted upon.
Who Should Use This Validator?
Software developers and integration engineers building ID scanning workflows will find this validator essential during development and QA. Testing scanning SDKs against known-good and known-bad AAMVA strings before deploying to production catches integration bugs early.
QA and compliance teams at businesses that scan driver's licences, dispensaries, alcohol retailers, gaming venues, car rental counters, and security checkpoints, can use this tool to audit scan output quality and confirm that their scanning hardware returns valid AAMVA strings.
Identity verification specialists working on KYC (Know Your Customer) systems can use the validator to triage whether a barcode failure originates from a structural error in the data or from a downstream parsing issue in their codebase.
Security researchers and forensic analysts examining the AAMVA data from a licence can use this validator to confirm data completeness before analysis. It also helps identify non-standard or jurisdiction-specific subfiles that fall outside the core AAMVA mandatory elements.
System administrators and data engineers handling bulk batches of scanned licence data can use this as a pre-processing check to filter out malformed records before ingestion into identity management systems.
For related document validation, the US Passport Number Validator and US Driver's License Validator cover complementary ID document formats.
What Insights Does the AAMVA Validator Give You?
The validator's primary output is a boolean pass/fail result, Valid or Invalid, displayed prominently in the result card. The details panel breaks down exactly which structural checks passed or failed:
Header checks:
- Compliance indicator, the string must begin with
@\n\x1e\r - File type indicator, must read
ANSI - Issuer Identification Number (IIN), six digits identifying the issuing jurisdiction
- AAMVA version number, two digits indicating the standard version used
- Jurisdiction version number, two digits for jurisdiction-specific extensions
- Number of entries, matches the count of subfiles declared in the header
Subfile structure checks:
- Subfile designator, confirms the
DLorIDsubfile type is present - Subfile offset and length fields, confirm the data element block is correctly framed
Mandatory data element checks: The validator confirms that the following DL subfile fields are present: DAC (first name), DCS (last name), DBB (date of birth), DBC (sex), DAG (street address), DAI (city), DAJ (state/province), DAK (postal code), DAQ (licence/ID number), DBA (expiry date), and DCF (document discriminator).
What the validator does NOT check:
- Whether the IIN corresponds to a real jurisdiction in the AAMVA registry
- Whether date fields contain logically valid calendar dates
- Whether optional jurisdiction-specific subfiles (e.g., ZC for California) contain correct fields
- Whether the licence number matches the expected pattern for the declared state (use the US Driver's License Validator for that)
- Whether the licence is genuine, active, or revoked
How to use this AAMVA calculator
Obtain the raw barcode data by scanning the PDF417 barcode on the back of a US or Canadian driver's licence with a PDF417-capable scanner or scanning SDK. The output should be a multi-line string starting with
@.Paste the full raw scan output into the AAMVA Barcode Data textarea. Ensure you paste the complete string, the typical length is 200 to 800 characters. Partial pastes are the most common cause of validation failures.
Click Validate to run the structural check. The validator processes the string client-side instantly.
Review the Result field, a green Valid badge confirms the barcode string is structurally compliant with the AAMVA DL/ID Card Design Standard. A red Invalid badge indicates a structural problem.
Check the details panel (shown on failure) for a breakdown of which specific checks failed, header format, subfile structure, or missing mandatory data elements. Use this information to pinpoint whether the issue is a scanner configuration problem, a truncated string, or a non-AAMVA document.
Use the result to decide next steps: if the barcode is structurally valid, proceed to parse the individual data elements using your application's AAMVA parsing library. If invalid, diagnose the root cause before attempting any downstream parsing.
Show formula & methodology ↓Show less ↑
Formula & Methodology
The AAMVA DL/ID Card Design Standard defines a precise byte-level format for the PDF417 barcode payload. The validator checks each structural layer in sequence. Header format (mandatory):@ LF RS CR ANSI [IIN:6d] [AAMVA version:2d] [jurisdiction version:2d] [num entries:2d]Where: -@= compliance indicator (0x40) -LF= line feed (0x0A) -RS= record separator (0x1E) -CR= carriage return (0x0D) -ANSI= file type identifier (literal, 5 chars including trailing space) -IIN= 6-digit issuer identification number -AAMVA version= 2-digit version (01–10 for versions 1 through 10) -jurisdiction version= 2-digit jurisdiction extension version -num entries= 2-digit count of subfile entries Subfile designator format:[type:2c] [offset:4d] [length:4d]WheretypeisDLorID, offset is the byte position of the subfile start, and length is the byte count. Data element format (within the DL/ID subfile): Each element is a 3-character data element identifier (e.g.,DAC,DCS,DBB) followed by the field value, terminated by a carriage return. Valid example:@ ANSI 636001090002DL00410278ZC03190024DLDAQD12345678 DCSSMITH DACJOHN DBB19800101 DBC1 DAG123 MAIN ST DAIANYT OWN DAJCA DAK902100000 DBA20280101 DCF83D9BN217QOThis string passes all checks: correct compliance indicator sequence, valid ANSI header, numeric IIN (636001 = California), AAMVA version 09, jurisdiction version 00, two subfile entries, DL subfile with all mandatory elements present. Invalid example:ANSI 636001090002DLDAQD12345678 DCSSMITHThis fails because the compliance indicator sequence (@\n\x1e\r) is missing, the subfile designator block is absent, and multiple mandatory data elements (DBB, DAC, DBC, DAG, DAI, DAJ, DAK, DBA, DCF) are not present.
Frequently Asked Questions