Free MRZ generator

What this MRZ generator writes

It builds the machine-readable zone of an ICAO 9303 travel document — two or three fixed-width lines of OCR-B text — from the fields you type, and computes every check digit the layout calls for, including the composite one. The result is drawn on a mock data page at the character pitch the standard specifies. The second mode turns the same writer into a seeded image set with ground truth.

The five layouts, and why the line length is not a detail

An MRZ is not free-form text. Every layout fixes how many lines there are, how many characters each line holds, and which field sits in which character position — so a string written for one layout cannot be read as another, even when the fields are identical. This generator covers the five ICAO 9303 layouts:

Values are padded to their field with the filler character <, and the separator between the primary and secondary identifier is two of them — NELSON<<CALLIE. A value longer than its field is cut, not wrapped: TD1 gives the name 30 characters, so a long surname loses its tail. One code is not ISO 3166: ICAO prints Germany as D, and this generator normalizes DEU to D so the field reads D<<, as a German document does.

Worked example: one passport, digit by digit

The record in the screenshot is a synthetic passport: NELSON, Callie, document 422016774, born 17 October 1988, expires 23 December 2027, optional data 572615374<5859. Written as TD3 it comes out as two 44-character lines:

P<USANELSON<<CALLIE<<<<<<<<<<<<<<<<<<<<<<<<<<<
4220167749USA8810171F2712239572615374<585990

The lower line is a fixed set of slices, and reading it means reading those slices rather than splitting on anything visible:

Every check digit uses the same arithmetic. Each character is given a value — 0–9 keep their value, A is 10 through Z is 35, and the filler is 0 — then multiplied by the repeating weights 7, 3, 1 and the total taken modulo 10. For the document number:

The products add to 119, and 119 modulo 10 is 9 — the character at position 10. The composite digit at the end is the same sum over a longer input: the document number with its check digit, the birth date with its check digit, the expiry date with its check digit and the optional data with its check digit, 39 characters in all, which gives 0. Nationality and sex are not in that input, which is why a wrong nationality can pass a composite check.

What a valid check digit does not prove

It proves the characters were copied without a transcription error. It does not prove the document is genuine: the algorithm is public, so a forgery carries correct digits too, and a reader that reports "MRZ check digits valid" has said nothing about security features, the chip, or whether the issuing state ever printed that number. That distinction matters when a demo like this one offers to produce a valid string from any input — the string is arithmetic, not authority.

Supported and not supported

Use the tool, or build it into your app

Limits worth knowing before you rely on it

Is a generated document number a real one?

No. Every value is drawn from fixed lists and a seeded random number generator, and no register anywhere knows the number. A correct check digit makes the string well-formed, not genuine — see the note above.

Why was my long surname cut in half?

Because the field is a fixed width and the generator pads or truncates to fit. ICAO wants the truncation done by removing whole name components and ending on a letter, so that a reader can tell a name was shortened; this page does not implement that rule, so a truncated name looks complete. Type a shorter name if you are testing truncation detection.

Why does an accented name produce a string that no reader accepts?

Because nothing is transliterated. The standard allows A–Z, 0–9 and the filler only, and Ü is none of those — it is written through as-is. Type the ASCII form (MUELLER) for a string that will read back.

Why is the date written 881017 rather than 1988-10-17?

That is the encoding: six digits, YYMMDD, no century. Which century a reader assumes is its own convention, which is why the dataset benchmark compares dates inside the century the MRZ encodes instead of inventing one.

Is the accuracy measured on the dataset a production number?

No. The images are synthesised, not photographed: the degradations model blur, glare, rotation, perspective, noise and JPEG loss, but a real camera adds sensor behaviour, print texture and operator error that this set does not contain. What it measures reliably is which conditions a reader survives, and where it starts losing characters.

Whose face is in the preview?

Nobody's. The portrait is drawn from primitives on the canvas — skin, hair, eyes and shoulders composited per record — so there is no photograph and no likeness of a real person anywhere in the page or in the exported images.