Learning & reference
Safe test data: the ranges reserved for exactly this
Standards bodies have set aside domains, IP addresses, phone numbers and identifiers that are guaranteed never to belong to anyone. Using them means your fixtures cannot email a stranger, dial a real phone or charge a real card, no matter where they end up. Here is the full set, and the places where no reserved range exists.
Why this matters more than it sounds
Test data does not stay in tests. It leaks into screenshots, demos, staging databases, support tickets and bug reports, and some of those get acted on by automated systems.
Fixtures outlive their purpose
A seeded staging database gets restored somewhere, a notification job runs against it, and the plausible address in row 4 receives real mail.
"Obviously fake" is a judgement call
A number that reads as invented to you is a working line to whoever owns it. Reserved ranges remove the judgement entirely.
Random valid is the worst case
Generating a Luhn-valid card number against a live issuer prefix produces something that can match a real card. Randomness does not make data safe; reservation does.
Domains and hostnames
In depth, with email validator test cases: example domains for testing.
| Use | Reserved by | Notes |
|---|---|---|
example.com example.net example.org | RFC 2606 | Reserved for documentation. They resolve and serve a real IANA page, so they are fine for examples but will produce live DNS and HTTP traffic if your tests actually call them. |
.test | RFC 2606, RFC 6761 | The best default for test fixtures. Can never be registered and is not expected to resolve. Every address in the HEXAQA email corpus uses it. |
.example | RFC 2606, RFC 6761 | For documentation and examples. |
.invalid | RFC 2606, RFC 6761 | Guaranteed not to resolve. Use when you want a lookup to fail. |
.localhost | RFC 2606, RFC 6761 | Always resolves to the loopback address. |
.local | RFC 6762 | Not a testing TLD. It is reserved for multicast DNS, so using it for test hostnames produces mDNS traffic and inconsistent resolution across platforms. |
Prefer .test over example.com for anything a test might actually
contact. The example.* domains are real, registered and served by IANA; a test suite that hits them in
a loop is sending real traffic to someone else's server.
IP addresses and networks
In depth, with the SSRF cases your code must refuse: reserved IP addresses.
| Range | Reserved by | Purpose |
|---|---|---|
| 192.0.2.0/24 | RFC 5737 | TEST-NET-1. Documentation and examples. |
| 198.51.100.0/24 | RFC 5737 | TEST-NET-2. Use when you need a second distinct network. |
| 203.0.113.0/24 | RFC 5737 | TEST-NET-3. A third. |
| 2001:db8::/32 | RFC 3849 | The IPv6 documentation prefix. |
| 3fff::/20 | RFC 9637 | A larger IPv6 documentation prefix, added in 2024. |
| 198.18.0.0/15 | RFC 2544 | Benchmarking. Not for documentation, and it can route inside some networks. |
| 100.64.0.0/10 | RFC 6598 | Carrier-grade NAT. Not a test range; real ISPs use it. |
| 00:00:5E:00:53:00 | RFC 7042 | MAC addresses reserved for documentation, …53:00 through …53:FF. |
| 64496–64511 | RFC 5398 | Autonomous System numbers for documentation. |
Phone numbers
Every UK and Australian range, plus phone field edge cases: test phone numbers.
| Region | Reserved | Notes |
|---|---|---|
| North America | 555-0100 to 555-0199 | The only 555 numbers actually reserved for fictional use. Other 555 numbers are assignable and some are assigned, so 555-1234 is not safe. |
| United Kingdom | 07700 900000–900999 | Ofcom drama range for mobiles. Landline equivalents exist per area, for example 0113 496 0000–0999 and 020 7946 0000–0999. |
| Australia | (02) 5550 xxxx | ACMA reserves blocks per area code for film and TV use. |
| Anywhere else | Check the regulator | Most national regulators reserve a drama or fiction block. If you cannot find one, a number that cannot dial at all, such as one with an invalid length, is safer than a plausible one. |
Payment card numbers
Published by payment processors for their sandboxes; these are from Stripe. They pass the Luhn check and only work in test mode. Declines, 3D Secure and form edge cases: test card numbers.
| Network | Number | Notes |
|---|---|---|
| Visa | 4242 4242 4242 4242 | Stripe's default test card. |
| Diners Club (14 digit) | 3622 720627 1667 | Shorter than 16, for length handling. |
| Mastercard | 5555 5555 5555 4444 | |
| Mastercard (2-series) | 2223 0031 2200 3222 | The 2221–2720 range many validators still reject. |
| American Express | 3782 822463 10005 | 15 digits, 4-digit CVV. Breaks anything assuming 16 and 3. |
| Discover | 6011 1111 1111 1117 | |
| JCB | 3566 0020 2036 0505 | |
| UnionPay (19 digit) | 6205 5000 0000 0000 004 | The longest length a card field must accept. |
Never generate your own. A Luhn check digit is trivial to compute, so a generated number on a live issuer prefix is indistinguishable from a real card and may be one. Use the published values, and your processor's own sandbox list for cases like declines and expiries.
Identifiers and secrets
UUIDs
The nil UUID 00000000-0000-0000-0000-000000000000 and the max UUID
ffffffff-ffff-ffff-ffff-ffffffffffff are both defined in RFC 9562 and safe as sentinels.
Any random v4 is effectively safe too.
Antivirus and spam
EICAR is a 68-byte string every scanner must flag as if it were malware; GTUBE is its spam-filter equivalent. Both are harmless and exist purely to prove detection works.
API keys and tokens
No reserved format exists. Use an obviously-fake prefix you control and a clearly non-random body, so a leaked fixture cannot be mistaken for a live credential by a secret scanner.
Private keys
Generate a throwaway key rather than copying one from a tutorial. Keys pasted into documentation get indexed, and anything using one is compromised by definition.
Where no reserved range exists
These are the ones people assume are covered and are not. Treat any value you invent here as potentially belonging to somebody real.
| Data | Situation | What to do instead |
|---|---|---|
| ISBN | No reserved block. A check-digit-valid ISBN you invent may identify a real book. | Use a prefix your organisation registered, or label the field synthetic and do not look it up. |
| IBAN / bank account | No reserved range. TEST as a bank code is a convention, not a standard. |
Use your bank's published sandbox values. |
| National ID numbers | Most countries reserve nothing, and some make misuse an offence. | Use structurally invalid values, or a documented test range where the government publishes one. |
| Postal addresses | No reserved addresses exist anywhere. | Invent a street name and use a reserved-looking town. Never use a real address you found. |
| Names | Any plausible name belongs to thousands of real people. | Unavoidable, and usually harmless on its own. It stops being harmless when combined with a real-looking address or phone number. |
| Company names | Real trademarks are not test data, however famous. | Compose from neutral words, for example Example Systems or Sandbox Labs. |
What this site uses
The same rules, applied to our own fixtures, so you can see them working.
| Where | What we use |
|---|---|
| Every email address in the email corpus | A subdomain of example.test. None of the 19 messages can be delivered anywhere. |
| The fake test-data generator | Reserved phone ranges, published card test numbers only, and synthetic company and place names. |
| The vCard fixture | example.test address and a 555-01xx number. |
| Security fixtures | EICAR and GTUBE, served from a separate hostname so a scanner blocking them cannot affect the rest of the site. |
Names and places are the honest exception. Our generator composes names and towns that are not real trademarks or real cities, but no reserved range exists for either, so a coincidence is always possible. The page says so rather than claiming more than it can.
Keep going
Fake data generator Synthetic PII for fixtures → Test card numbers →
More from Learning
Guides and references for test data, file handling and AI evals. All free, no sign-up. See the full hub.