U.S. Passport Number Generator

Continue in the tool

More pages for this tool

U.S. passport number for test fixtures

A boarding form or booking API that expects a 9-digit passport number can be tested without touching a real document: this page shows how the generator produces that synthetic value, what happens with a short seed, and how to reproduce the same number across separate CI runs.

How the 9-digit value behaves in a fixture

The generator always returns exactly 9 characters, digits only, no letter and no separator: `raw` and `formatted` are identical here, unlike the EIN generator in the same kit, which inserts a dash at position 2. If the seed you pass in is shorter than 9 digits, `createUsPassportNumber` pads the rest with zeros on the right, so a seed of '42' becomes '420000000', not '000000042'; a test expecting the meaningful digits at the start of the string, rather than at the end, needs to pass in a seed that already has all 9 characters ready, not a short one it expects to be padded on the left.
To reproduce the same number across separate CI runs, `generateUsPassportNumber` accepts a fixed `DigitSource` and draws 9 digits from it; internally the generator discards any draw that lands on a 9-digit repeated-digit sequence, like 111111111, and retries, up to 20 times, before falling back to a default value. `createUsPassportNumber`, called with a fixed value you choose yourself, skips that check entirely, so you can deliberately force an edge case like 111111111 into a test that needs to verify how the form reacts to that exact pattern, something the random path will never hand you on its own.
For a contract test, the field that matters is always `raw`: since a passport number has no separator, `formatted` returns the same 9-digit string, so there is no raw-versus-formatted split to worry about here the way there is for the EIN or ITIN in the same kit. That simplifies the assertion: a test only needs to check `/^\d{9}$/` against whatever the form receives, with no dash, space or separator position to account for anywhere between the generator's output and the input field under test.

Three seeds, three generation behaviors

Full 9-digit seed

Input: createUsPassportNumber('987654321')
Expected output: 987654321

A seed that already has 9 digits passes through unchanged, no padding and no truncation, ready for a test that needs one fixed, predictable value.

Short seed padded with zeros

Input: createUsPassportNumber('42')
Expected output: 420000000

A 2-digit seed becomes 9 by padding the remainder with zeros on the right, so the meaningful digits end up at the start of the string, not the end.

Manually forced repeated sequence

Input: createUsPassportNumber('111111111')
Expected output: 111111111

This pattern never comes out of `generateUsPassportNumber` because the random draw discards a repeated digit, but `createUsPassportNumber` accepts it since it skips that check, useful for deliberately testing an edge case.

Full tool FAQ

Does a U.S. passport number have a public check digit?

There is no simple public checksum to validate issuance from the number alone.

Will the generated number be accepted by real systems?

Why use 9 digits?

Does this generator create MRZ?

Can I use it in KYC tests?

Is the number sent anywhere?

Should I combine it with real names?

When do I need official data?

Frequently asked questions

What happens if my test seed contains letters?

They get stripped before generating: `createUsPassportNumber` keeps only the digits from the input, so a seed like 'AB123' becomes just '123' and the rest is padded with zeros up to 9 characters.

Can I pin an exact value for a snapshot test?

Yes, pass the literal 9-digit value straight into `createUsPassportNumber`; since there is no random draw on that path, the return value is always the same text you passed in, with no transformation beyond zero-padding a short seed.

Can the random generator produce something like 111111111?

Not through the random path: `generateUsPassportNumber` discards a repeated-digit sequence and retries; but you can force that exact value manually with `createUsPassportNumber` to test how the form reacts to that edge case.

How do I test a form that should reject fewer than 9 digits?

Feed a shorter string, say 8 digits, straight into validation (`isValidUsPassportFormat`), which returns false; that confirms the error path without having to build a full-length number just to make it fail on purpose.

Next steps

Continue in the tool

Open full tool

U.S. passport number for test fixtures

How the 9-digit value behaves in a fixture

The generator always returns exactly 9 characters, digits only, no letter and no separator: `raw` and `formatted` are identical here, unlike the EIN generator in the same kit, which inserts a dash at position 2. If the seed you pass in is shorter than 9 digits, `createUsPassportNumber` pads the rest with zeros on the right, so a seed of '42' becomes '420000000', not '000000042'; a test expecting the meaningful digits at the start of the string, rather than at the end, needs to pass in a seed that already has all 9 characters ready, not a short one it expects to be padded on the left.

To reproduce the same number across separate CI runs, `generateUsPassportNumber` accepts a fixed `DigitSource` and draws 9 digits from it; internally the generator discards any draw that lands on a 9-digit repeated-digit sequence, like 111111111, and retries, up to 20 times, before falling back to a default value. `createUsPassportNumber`, called with a fixed value you choose yourself, skips that check entirely, so you can deliberately force an edge case like 111111111 into a test that needs to verify how the form reacts to that exact pattern, something the random path will never hand you on its own.

For a contract test, the field that matters is always `raw`: since a passport number has no separator, `formatted` returns the same 9-digit string, so there is no raw-versus-formatted split to worry about here the way there is for the EIN or ITIN in the same kit. That simplifies the assertion: a test only needs to check `/^\d{9}$/` against whatever the form receives, with no dash, space or separator position to account for anywhere between the generator's output and the input field under test.

Three seeds, three generation behaviors

Full 9-digit seed

Input: createUsPassportNumber('987654321')
Expected output: 987654321

A seed that already has 9 digits passes through unchanged, no padding and no truncation, ready for a test that needs one fixed, predictable value.

Short seed padded with zeros

Input: createUsPassportNumber('42')
Expected output: 420000000

A 2-digit seed becomes 9 by padding the remainder with zeros on the right, so the meaningful digits end up at the start of the string, not the end.

Manually forced repeated sequence

Input: createUsPassportNumber('111111111')
Expected output: 111111111

Full tool FAQ

Does a U.S. passport number have a public check digit?

There is no simple public checksum to validate issuance from the number alone.

Will the generated number be accepted by real systems?

Why use 9 digits?

Does this generator create MRZ?

Can I use it in KYC tests?

Is the number sent anywhere?

Should I combine it with real names?

When do I need official data?

Frequently asked questions

What happens if my test seed contains letters?

They get stripped before generating: `createUsPassportNumber` keeps only the digits from the input, so a seed like 'AB123' becomes just '123' and the rest is padded with zeros up to 9 characters.