Every so often a load test goes out with a plausible-looking IP address hard-coded into it and lands on somebody’s production server. The address was picked because it looked like an address. That is the whole failure.
Standards bodies solved this decades ago by reserving blocks that are guaranteed to belong to nobody. Using them costs nothing and removes the entire category of accident.
Last updated: 30 August 2026 · Tools SoShareIT editorial team
The three documentation blocks
RFC 5737 reserves three IPv4 ranges specifically so that documentation and test data never collide with a real host: 192.0.2.0/24, 198.51.100.0/24 and 203.0.113.0/24.
Three, rather than one, for a reason worth knowing. Many examples need to show traffic between separate networks — a client, a server and a gateway — and a single block forces you to pretend three different networks share a subnet, which quietly teaches the wrong thing. With three blocks each party in a diagram gets its own network and the example stays honest.
IPv6 has one equivalent, 2001:db8::/32, reserved by RFC 3849. If you have ever wondered why every IPv6 example on the internet starts 2001:db8, that is why.
Private is not the same as reserved
The RFC 1918 private ranges — 10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16 — are the ones most people reach for, and they are not the same thing as the documentation blocks. The distinction matters in exactly one situation, but it is a situation you will hit.
A private address is guaranteed not to be routed on the public internet. It is not guaranteed to be unused, because it is almost certainly in use on the very network you are testing from. Hard-code 192.168.1.1 into a test and there is a good chance you have just aimed it at the router under somebody’s desk.
The documentation blocks carry no such risk. Nothing is supposed to answer on them anywhere, which is what makes them safe to bake into a fixture that will run on machines you have never seen.
Swipe the table sideways to see every column.
| Use case | Correct range | Why not the other one |
|---|---|---|
| A fixture committed to a shared repo | 192.0.2.0/24 |
Private ranges are live on someone’s LAN |
| Documentation and diagrams | All three TEST-NET blocks | One block cannot show three networks |
| Actual internal infrastructure | RFC 1918 private space | TEST-NET is for examples, not deployment |
| Testing the local machine | 127.0.0.1 |
Nothing leaves the host |
| An IPv6 example | 2001:db8::/32 |
The only reserved documentation prefix |
Domains you can use in any example
RFC 2606 reserves example.com, example.net and example.org, plus four top-level domains that will never be delegated: .test, .example, .invalid and .localhost. RFC 6761 later formalised how resolvers should treat them.
Each has a distinct job, and picking the wrong one produces a test that passes for the wrong reason:
.testis for hostnames in a test environment. It never resolves publicly, so a leaked request fails fast instead of reaching a stranger..invalidis guaranteed not to be valid — the correct choice when you need input that must fail. Usingexample.comfor a negative test is a bug, because it is a perfectly valid domain..localhostalways resolves to the loopback interface, by specification rather than by convention.example.comand its siblings are held by IANA and will never be sold, which is what makes them safe to print in documentation that outlives you.
The test email trap
This one deserves its own section because it does measurable harm and looks harmless.
An address like [email protected] in a signup fixture is a real, deliverable mailbox belonging to a real person. Every time your suite runs, they get mail. If the suite runs in CI on every push, they get a lot of mail, and there is no way for them to make it stop.
The fix costs one character: [email protected]. It is guaranteed undeliverable, it will never belong to anyone, and no bounce reaches a human. For a negative test — asserting that your validator rejects bad input — use test@invalid instead, because that one is guaranteed to fail validation rather than merely fail to deliver.
The same logic applies to phone numbers. In the North American plan only 555-0100 through 555-0199 are reserved for fiction. Every other 555 number can be assigned and some are.
Quick reference
The full tables — every reserved IP range with the RFC that defines it, the reserved domains, and the test card numbers processors publish — sit on the front page of Tools SoShareIT, where every value is click-to-copy. The editorial policy explains why we cite the RFC number next to each row rather than asking you to take our word for it.
If you take one rule away: reserved beats plausible. A value that a standards body set aside is safe forever, and a value that merely looks unused is safe until the day it isn’t.
Frequently asked questions
Which IP address should I use in documentation?
One of the three RFC 5737 blocks: 192.0.2.0/24, 198.51.100.0/24 or 203.0.113.0/24. For IPv6 use 2001:db8::/32, reserved by RFC 3849. All four are guaranteed to belong to nobody, which is why every well-written standards document uses them.
Can I just use 192.168.1.1 in my tests?
You can, and it is riskier than it looks. Private ranges are guaranteed not to be routed publicly but they are absolutely not guaranteed to be unused — 192.168.1.1 is the router on a great many of the networks your test will run on. The documentation blocks carry no such risk.
What email address should I use for test signups?
Anything at example.com, example.net or example.org. These are held permanently by IANA and will never be delivered or sold. Never use [email protected] — that is a real mailbox belonging to a real person who receives every message your CI pipeline sends.
What is the difference between .test and .invalid?
Job, not status. .test is for hostnames in a test environment and simply never resolves publicly. .invalid is guaranteed to be invalid, which makes it the right choice for negative tests. Using example.com to assert that your validator rejects bad input is a bug, because it is a perfectly valid domain.
Are 555 phone numbers safe to use?
Only 555-0100 through 555-0199. That is the single block the North American Numbering Plan reserves for fiction. Every other 555 number can be and sometimes is assigned to a real subscriber.