Use example.com, example.net and example.org for domains, and 192.0.2.0/24, 198.51.100.0/24 and 203.0.113.0/24 for IPv4 addresses. Standards documents reserve these names and ranges for documentation, so a reader who pastes your sample into a real client does not send traffic to someone else's server.
Why made-up hostnames are a risk
Writers often invent a hostname such as api.mycompany.io or acme-internal.com because it looks realistic. The trouble is that a name you invented may be registered by someone else, or may be registered next year. Readers copy the sample, run it, and the request goes to a stranger.
That is a small leak at best. At worst, a sample that sends a bearer token, a webhook payload or a test file to a hostname you do not control hands data to whoever owns it. Examples also get pasted into configuration, and configuration lives longer than tutorials do.
What the standards reserve
RFC 2606 reserves four top level names for documentation and testing, and also reserves three second level names: example.com, example.net and example.org. RFC 5737 sets aside three IPv4 blocks for documentation: TEST-NET-1 (192.0.2.0/24), TEST-NET-2 (198.51.100.0/24) and TEST-NET-3 (203.0.113.0/24). It says addresses in those blocks should not appear on the public Internet. The IPv6 documentation prefix is defined separately in RFC 3849, which RFC 5737 points to.
| You need | Safe choice | Standard |
|---|---|---|
| A website or API host | api.example.com | RFC 2606 |
| A second, unrelated host | service.example.net | RFC 2606 |
| One IPv4 address | 192.0.2.10 | RFC 5737 |
| Three separate networks | 192.0.2.0/24, 198.51.100.0/24, 203.0.113.0/24 | RFC 5737 |
| An email address | user@example.com | RFC 2606 |
Steps to apply this in your docs
- Search your docs repository for hostnames and IP addresses inside code blocks. A simple regular expression over the markdown files finds most of them.
- Replace invented domains with a subdomain of example.com. Subdomains keep the sample readable, for example
payments.example.com. - Replace private looking addresses such as 10.x.x.x only if the sample is not about private networks. If the lesson is about a private range, keep it and say so.
- Put one sentence near the first example telling readers to substitute their own host. Make the substitution obvious by using a consistent placeholder name across the whole docs set.
- Add a lint step to the docs build that fails on hostnames outside an allowed list. This stops the habit from returning.
Where this does not help
Reserved names stop accidental traffic to strangers. They do not stop a reader from swapping in their own host and then copying a risky pattern, such as disabling certificate checks. Keep the sample itself safe as well as the address.
Also remember that your real production hostnames should not appear in public samples. They tell attackers where to look and they create support load when readers try them.
Try it yourself
Docs and sample projects have dependencies too. Walk through how an inventory of those dependencies is built.
Click through it at your own pace, or open it full screen.
Safeguard's dependency scanning and SBOM generation cover the sample projects your docs link to, the same way they cover production code. There is also a free scan at https://gold.safeguard.sh/scan.
Quick check
Is example.com a real website?
It is a domain reserved for documentation by RFC 2606, so it is safe to use in examples. Do not rely on it to host anything you build.
Can I use a 10.0.0.0 address in docs?
You can, but those are real private addresses used on many networks. The TEST-NET blocks are reserved so they cannot clash with a reader's network.
Sources
Last reviewed: 19 October 2026.
