Learning & reference

Synthetic PII for test fixtures and AI evals

Fake personal data is only safe if it cannot reach a real person. Some fields have a range a standards body reserved for exactly this, and some have none. This page separates the two, because treating "unlikely to collide" as "safe" is how test data ends up in a stranger's inbox.

Safe, because it is reserved

These come from ranges set aside so they will never be assigned to anyone.

FieldUseWhy it is safe
Emailalex@example.testRFC 2606 reserves .test. It is never delegated in the public DNS, so mail cannot be delivered. All reserved domains
Phone (N. America)+1 212 555 0142NANPA reserves only 555-0100 to 555-0199 for fiction. The rest of 555 is not reserved. By country
Phone (UK)07700 900123Ofcom reserves 07700 900000 to 900999 for drama. All UK ranges
Card number4242 4242 4242 4242Published by Stripe for its sandbox. Works only in test mode. Every network and decline code
IPv4 address192.0.2.10RFC 5737 reserves 192.0.2.0/24 for documentation. All reserved ranges
IPv6 address2001:db8::10RFC 3849 reserves 2001:db8::/32 for documentation.
URLhttps://api.example.comRFC 2606 reserves example.com, .net and .org.

Only unlikely to collide

No standards body reserves these. Generated values are probably fine and never guaranteed.

Names

There is no reserved name. "Lucas Novak" is a generated name and almost certainly also a real person. Pair names with a reserved email so a record is obviously synthetic as a whole.

Street addresses

Nothing is reserved. Make them undeliverable instead: an invented town, or a postal code that does not match the region.

National identifiers

Some schemes have test ranges and many do not. Check the issuing authority for your country before generating one, and never generate a value that passes the real checksum on a live range.

The general rule: where a reserved range exists, use it. Where none exists, make the record obviously synthetic as a whole rather than trying to make one field safe.

Why this matters more for AI evals

An eval set travels further than any other test data.

A unit test fixture stays in your repo. An eval set is pasted into prompts, sent to model providers, written to tracing tools, shown in vendor dashboards and shared in notebooks. A real customer record in an eval set is copied into all of those. Synthetic records from reserved ranges can go anywhere, which is exactly what an eval set does.

There is a second reason. Models are good at recognising real-looking personal data and may refuse, redact or behave differently around it. If your production traffic contains real PII and your eval set contains obviously fake PII, check that the difference is not changing what you are measuring.

Generate it

A browser tool that uses the reserved ranges above for every field that has one.

The fake data generator produces people, emails, US phone numbers, addresses, test card numbers, IBANs, companies and dates of birth as JSON or CSV. It runs in your browser and uploads nothing. It is capped at 500 rows and is random rather than seeded, so it suits fixtures and demo data better than large repeatable datasets. For deterministic records at volume, the mock API serves 250 users that are identical on every call.

Questions

Is data from Faker safe to use in tests?

Not automatically. Realistic is the problem: a generated email on a real domain can be delivered and a generated phone can ring a stranger. Use reserved ranges wherever one exists.

Which fake email domain is safe?

Anything under .test, .example or .invalid, or example.com, .net or .org. Use .invalid when you need a guarantee the address cannot resolve at all.

Can I generate my own test card numbers?

No. A number you generate on a live issuer prefix may be a real account. Use your processor's published sandbox numbers.

Is there a reserved range for names or addresses?

No. Make the record obviously synthetic as a whole instead.

Why does this matter for AI evaluation data?

Eval sets are copied into prompts, logs and vendor dashboards. Synthetic records from reserved ranges can travel anywhere, which is what an eval set does.

Keep going

Generate fake data Safe test data → Synthetic data for AI evals →

More from Learning

Guides and references for test data, file handling and AI evals. All free, no sign-up. See the full hub.

Synthetic data for AI evalsWhat you can download, what you buildRAG test corpusDocuments with extraction trapsJSONL for evalsThe format, and ten ways it breaksMock API for agentsRecords, pagination, failures on demandSafe test dataReserved domains, IPs, numbers & cardsTest card numbersEvery brand, declines, 3D SecureTest phone numbersReserved US, UK and Australian rangesReserved IP addressesDocumentation ranges and SSRF casesExample domains.test, .invalid, example.com, and trapsQA test stringsUnicode, emoji, injection & edge casesFilename compatibilityWhat breaks across Windows, Mac & LinuxFile systemsPOSIX, NTFS, APFS, ext4, SMB, NFS, NASFile signaturesMagic numbers that identify every formatCharacter encodingsUTF-8, UTF-16, BOM & normalizationUpload validationThe checklist, with a file for each checkMIME typesThe right Content-Type for every extensionHTTP status codesEvery code and when you actually see itDates & timesISO 8601, epoch, Excel serials, DSTHTTP headersContent-Type, Disposition, Range, CORSRegex cheat sheetSyntax, flags and ready-made patternsGenerate files (CLI)Make test files on any OSCrypto & certificatesSSL/PEM, hashing, encryptionWeb app testingWhat to test, with a file for each caseDesktop app testingPaths, names, encodings and savingMobile app testingPickers, photos, flaky networksCLI testingArguments, pipes and exit codesLarge file upload testingDefault limits, 413s and exact sizes1 GB test file1 GB and 2 GB, with SHA-25610 GB test fileMake one locally in secondsDownload speed test files10 MB to 2 GB of random data