A Developer's Guide to Safe Test Data

Two very different kinds of 'fake'

When people say they need 'fake data' for testing, they usually mean one of two very different things: data that's structurally realistic but harmless by design (like a UUID, or a phone number in a block specifically reserved for fiction), or data that's algorithmically valid in a way that could be mistaken for — or misused as — the real thing (like a credit card number that happens to pass a Luhn checksum). Xrandom's developer tools are deliberately built to stay in the first category.

The officially reserved ranges Xrandom actually uses

Several of Xrandom's tools lean on ranges specifically set aside by real standards bodies for exactly this purpose, rather than inventing their own convention: the US Phone Number Generator uses the 555-0100 through 555-0199 block reserved by the North American Numbering Plan Administration since 1994 specifically for fiction and testing. The Test Payment Card Picker goes a step further and doesn't generate numbers at all — it only selects from Stripe's own officially published sandbox test numbers, which are meaningless outside Stripe's test mode.

Where 'realistic but harmless' is the right bar

Not everything needs a reserved-by-law range to be safe — it just needs to be clearly non-sensitive by construction. The Test Bank Account / IBAN Generator computes genuinely valid checksums using the real mod-97 algorithm, but an account or routing number alone can't move money without additional authorization — unlike a full card number, it's information routinely printed on a physical check. The ULID / Nano ID Generator and Business Reference Number Generator don't touch sensitive data categories at all; they're just identifiers.

The line Xrandom won't cross

The clearest contrast is what's deliberately missing: Xrandom has no credit card number generator and no Social Security Number generator, despite both being common requests. Algorithmically generating a number that passes a real checksum (Luhn for cards, or a plausible SSN format) produces an artifact that's functionally identical whether it's labeled 'for testing' or not — the same technique is used in real card-testing fraud. There's a well-documented historical precedent for SSN-shaped 'sample' numbers too: a famous 1938 wallet-insert sample SSN was printed with a real format, and for decades afterward was reused as an actual SSN by people who assumed it was fake, permanently entangling one real person's identity with it.

A practical checklist for your own test data

• Prefer officially reserved ranges (like 555 phone numbers) over inventing your own when one exists.
• For payment testing, use your payment processor's own published sandbox test numbers rather than generating numbers that pass a real checksum.
• Never generate SSN-shaped or government-ID-shaped numbers for samples, even clearly labeled as fake — use obviously non-numeric placeholders instead.
• Remember that 'passes validation' and 'safe to generate' are different questions — a number can be structurally perfect and still be the wrong thing to algorithmically produce.