There is a particular kind of bug that only shows up in production, months later, in someone else's inbox. A QA engineer writes a fixture with the phone number +1 415 555 8721 because it looks obviously fake. A load test runs against 10.0.0.5 — which is a real host on the customer's network. A signup confirmation goes to test@gmail.com, an address a real person has owned since 2004 and who now receives several hundred of these a year.
None of these are exotic failures. They happen because "obviously fake to a human" and "guaranteed not to exist" are completely different properties, and only the second one is safe.
The good news is that standards bodies have been quietly solving this problem for thirty years. There are blocks of phone numbers that no carrier will ever assign, IP ranges that cannot route, domains that can never be registered, and identifier ranges permanently excluded from issuance. They exist precisely so that documentation, textbooks, screenshots and test fixtures have somewhere safe to point. This is a reference to them.
The rule underneath all of it: prefer a range whose emptiness is guaranteed by a registry over a value that merely looks implausible. Implausible values get assigned. Reserved ones do not.
Telephone numbers
North America (NANP)
The North American Numbering Plan reserves 555-0100 through 555-0199 within any area code for fictional use. That is one hundred numbers per area code, and they are the only ones you should use.
This is narrower than the folklore suggests. The widespread belief that "all 555 numbers are fake" is wrong and has been for decades — the 555 prefix is a real central-office code, and numbers outside the 01xx block are assignable. 555-1212 in particular is directory assistance across most of the plan, and it is very much live.
So the safe form is (area) 555-01NN, where NN is 00 to 99, and where the area code itself should be a real, assigned one if you want the number to survive a format validator.
United Kingdom
Ofcom reserves specific blocks for drama and documentation, and these are much larger than the North American allocation. The pattern is xxx 496 0000 to xxx 496 0999 for geographic numbers in most area codes, plus dedicated ranges elsewhere:
| Kind | Reserved range |
|---|---|
| London | 020 7946 0000 – 020 7946 0999 |
| Leeds | 0113 496 0000 – 0113 496 0999 |
| Manchester | 0161 496 0000 – 0161 496 0999 |
| Mobile | 07700 900000 – 07700 900999 |
| Freephone | 08081 570000 – 08081 570999 |
| Premium rate | 0909 8790000 – 0909 8790999 |
Elsewhere
Australia's ACMA reserves fictitious-use ranges for radio and television drama, including landline numbers in the (0x) 5550 xxxx form and a small mobile block. Many other regulators have no such scheme at all, which is worth knowing before you assume one exists: for most countries the honest answer is that there is no reserved range, and the best you can do is generate a structurally valid number and never dial it.
IPv4 and IPv6 addresses
This is the best-served category, because the IETF has been explicit.
RFC 5737 reserves three IPv4 blocks specifically for documentation. They are guaranteed not to be routed on the public internet:
192.0.2.0/24— TEST-NET-1198.51.100.0/24— TEST-NET-2203.0.113.0/24— TEST-NET-3
RFC 3849 reserves 2001:db8::/32 for IPv6 documentation. It is enormous — you will not exhaust it.
These are the addresses to put in a fixture, a diagram, or a log-parsing test. Crucially, they are not the same as the private ranges.
Why RFC 1918 is the wrong choice for fixtures
10.0.0.0/8, 172.16.0.0/12 and 192.168.0.0/16 are private (RFC 1918), and a lot of test data uses them by reflex. The problem is that private does not mean unused — it means locally used. 192.168.1.1 is almost certainly a live router on the network of whoever runs your test suite. A fixture containing it, fed into anything that opens a connection, will reach a real device.
Reserve RFC 1918 addresses for tests that are genuinely about private networking, and use the RFC 5737 blocks for everything else. Two more ranges worth recognising, mostly so you know not to generate into them: 100.64.0.0/10 is carrier-grade NAT space (RFC 6598), and 169.254.0.0/16 is link-local, which on cloud instances is where the metadata service lives at 169.254.169.254.
Domain names and email addresses
RFC 2606, reinforced by RFC 6761, reserves four top-level domains and three second-level domains permanently. None can be registered by anyone, ever:
.test— for testing.example— for documentation.invalid— guaranteed to fail resolution, useful when you want a hard error.localhost— always resolves to the loopbackexample.com,example.net,example.org— maintained by IANA with a placeholder page
For email, this makes anything@example.com the correct choice for a fixture. Mail addressed there cannot be delivered, which is exactly the point: a test that accidentally triggers a real send fails loudly instead of reaching a stranger.
The alternative you will see in older codebases — test@test.com, foo@gmail.com, admin@company.com — all point at domains someone owns. test.com is a real, registered domain. So is almost every plausible-looking name you might invent.
One genuinely useful trick that is not a reserved range: subaddressing, the user+tag@domain form defined in RFC 5233. If you need mail that actually arrives during an integration test, you+signup-test-41@yourdomain.com delivers to your own inbox while giving each test run a distinct address. Use reserved domains when delivery must fail; use subaddressing when it must succeed.
MAC addresses
RFC 7042 carves documentation ranges out of IANA's own OUI:
00-00-5E-00-53-00through00-00-5E-00-53-FF— unicast, for documentation01-00-5E-90-10-00through01-00-5E-90-10-FF— multicast, for documentation
Two structural rules matter more than the exact range, though. The low bit of the first octet is the unicast/multicast flag, and the next bit is the local/global flag. A randomly generated MAC has a 50% chance of claiming to be a multicast address, which is nonsense for a device identifier. If you must generate outside the documentation range, set the local bit and clear the multicast bit — the second hex digit becomes one of 2, 6, A, or E. Those are locally administered addresses and no manufacturer owns them.
Autonomous system numbers
RFC 5398 reserves 64496–64511 for 16-bit documentation ASNs and 65536–65551 for 32-bit. Private-use ASNs (RFC 6996) are 64512–65534 and 4200000000–4294967294. For a BGP config in a document or a test, use the RFC 5398 ranges; a real network's fixture will otherwise eventually be pasted into a real router.
National identifiers
US Social Security Numbers
The Social Security Administration has never issued, and has committed never to issue:
- any number with area (first three digits)
000,666, or in the range900–999 - any number with group (middle two digits)
00 - any number with serial (last four digits)
0000
Area 900–999 is the widest and safest block. Separately, the SSA reserves 987-65-4320 through 987-65-4329 explicitly for use in advertising, which is a useful signal: these are the numbers the issuing authority itself puts on a poster.
Note that since the 2011 move to randomised assignment, the older heuristics for spotting a fake SSN by geography no longer work. Area codes no longer encode the state of application.
Elsewhere
Most national identifier schemes have no reserved test range. The UK's NHS number is a useful exception in spirit: it carries a mod-11 check digit, and the number ranges used for testing in NHS synthetic datasets are documented within the health service rather than by a public standard. For everything else — national insurance numbers, tax identifiers, passport numbers — the realistic approach is to generate a structurally valid, checksum-correct value and rely on the astronomical unlikelihood of collision, while never presenting it to any real system.
Payment card numbers
There is no reserved range for card numbers, but there is something almost as good: a set of test PANs that every major processor recognises and that no issuer has assigned. These are published by the card networks and by processors like Stripe and Adyen, and they are the safest choice when you are testing against a payment sandbox:
| Network | Test number |
|---|---|
| Visa | 4111 1111 1111 1111 |
| Mastercard | 5555 5555 5555 4444 |
| American Express | 3782 822463 10005 |
| Discover | 6011 1111 1111 1117 |
| JCB | 3530 1113 3330 0000 |
All of them satisfy the Luhn check, so they will pass a client-side validator, and all are rejected by the live networks.
For volume — a thousand rows in a seed script rather than five cases in a checkout test — a generated Luhn-valid number under a real IIN is the practical option. The critical rule is the same one that governs this whole page: it may pass your validator, but it must never be presented to a payment processor in production.
Barcodes and product codes
GS1 reserves prefixes 02 and 20–29 within GTIN-13 for restricted distribution — internal use within a company, typically store-level weighed goods. Numbers in those prefixes are never globally unique and are never assigned to a manufacturer, which makes them the right choice for a catalogue fixture. Prefixes 978 and 979 are ISBN, 977 is ISSN, and 99 is coupons; avoiding those keeps your test data from being interpreted as a book.
What has no reserved range
It is worth being honest about the gaps, because assuming a reservation exists when it does not is how collisions happen.
IBANs have no reserved block. ISO 13616 defines the structure and the mod-97 check, but no country has set aside a bank code for testing. A generated IBAN with valid check digits is structurally indistinguishable from a real one; it is safe only because the specific bank-and-account combination is unlikely to exist, not because a registry guarantees it. Never initiate a payment to one.
Neither do most postal codes, VAT numbers, or company registration numbers. Generated values in these categories are plausible, checksum-correct, and entirely unbacked by any guarantee of non-existence.
For those categories, the discipline has to come from process rather than from the number itself: keep synthetic data in synthetic environments, label it, and never let a fixture cross into a system that can act on it.
A checklist
Before a value goes into a fixture, ask three questions:
- Is there a reserved range for this? If yes, use it — the guarantee is free.
- If not, is the value structurally valid? A number that fails at the first validator never exercises the code behind it, which defeats the purpose of the fixture.
- What happens if this value escapes into a real system? If the answer is "an email reaches a stranger" or "a packet reaches a live host", pick differently.
Most of the ranges on this page have existed for longer than the codebases that ignore them. They cost nothing to adopt and they close an entire category of embarrassing failure.