A "random IP generator by city" returns sample IP addresses, but the city-specific tools you find online usually pull values that already belong to real ISPs, businesses, and homes in those regions. The Random IP Address Generator takes a different approach: it draws values only from the documentation IPv4 blocks reserved by RFC 5737 (192.0.2.0/24, 198.51.100.0/24, and 203.0.113.0/24), the private IPv4 blocks reserved by RFC 1918 (10.0.0.0/8, 172.16.0.0/12, and 192.168.0.0/16), and the documentation IPv6 prefix reserved by RFC 3849 (2001:db8::/32). Because none of those ranges are routed on the public Internet, the addresses are safe to print in tutorials, paste into test fixtures, drop into screenshots, and use in configuration samples without naming someone else's live host. Generation runs locally in the browser with cryptographic randomness, the list enforces uniqueness inside each batch, and the tool never probes, pings, uploads, or reserves any address.
Why City-Based IP Lists Can Be Risky for Documentation
The search results for "random IP generator by city" are dominated by tools that produce lists tied to specific countries and cities. India, Canada, Germany, France, and the United Kingdom each have their own generator pages, and the results usually look like a real public address with a city and coordinates attached. The problem is that those addresses are not fictional. They sit inside live allocations owned by ISPs, hosting providers, and home networks. If you put them into a tutorial, a screenshot, a training deck, or a recorded demo, you are publishing a working target that someone else owns.
That creates three practical risks. First, the address may resolve to a real service, so a curious reader can knock on that door with a traceroute or a port scan. Second, the address may overlap with a customer's production network, so a config sample that looks innocent can collide with their routing table. Third, ownership can change, which means a "Paris" address today could be reassigned tomorrow, breaking any test that depended on the city label being stable. RFC-reserved ranges sidestep all three risks because they are explicitly set aside for examples and documentation and are not routed on the public Internet.
What the Generator Actually Picks From
Three modes are available, and each one draws only from a published RFC range. The generator rejects any value outside those blocks, excludes the network and broadcast host octets in IPv4 examples, and deduplicates the result with a bounded retry loop so a single click never returns the same address twice.
| Mode | Source RFC | Reserved block | Routable on the public Internet | Typical use |
|---|---|---|---|---|
| Documentation IPv4 | RFC 5737 | 192.0.2.0/24, 198.51.100.0/24, 203.0.113.0/24 | No | Tutorials, screenshots, sample configs, test fixtures |
| Private IPv4 | RFC 1918 | 10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16 | No (locally meaningful only) | Lab networks, VPN plans, training labs, internal documentation |
| Documentation IPv6 | RFC 3849 | 2001:db8::/32 | No | IPv6 examples, dual-stack docs, training material |
The IANA IPv4 Special-Purpose Registry lists each of these ranges and confirms their reserved status. Anyone reading your docs can look the block up and immediately see that it is meant for examples, which makes the surrounding text easier to trust.
How to Generate the Address List
The interface is intentionally short so the safety guarantees cannot be skipped. The same three-step flow works for documentation IPv4, private IPv4, and documentation IPv6 output.
- Choose a mode. Pick Documentation IPv4 for tutorials and screenshots, Private IPv4 when you need an address that resembles one you would actually deploy on an internal LAN or VPN, or Documentation IPv6 for IPv6 examples and dual-stack material.
- Enter a count between 1 and 100 and press Generate addresses. The browser uses Web Crypto to pick blocks and host values, then deduplicates the list so no value appears twice in the same batch.
- Copy the result into your fixture, document, or lab plan. If you generated private IPv4 values, review each one against your existing network before assigning it to a host, subnet, VPN, or route.
If your sample data set needs more than 100 rows, generate in batches and append the lists, treating each click as an independent deduplicated run.
Adding a City Label Without Touching a Public IP Block
Most readers searching for "random IP generator by city" want their sample data to look geographic, not necessarily to live inside a real regional allocation. The cleanest way to get that look is to separate the address column from the city column in your fixture and populate each from a different source.
Pull the IP from the generator's documentation or private range, then put a city label in its own field, drawn from a small static list such as Paris, Toronto, Mumbai, Berlin, or Glasgow. Your training data, demo dashboard, and screenshot can show a Paris host with a 198.51.100.x address or a Mumbai host with a 10.x.x.x private address, and a reader who copies the address still gets a value reserved for examples. The city stays a label, not a routing target, so reassignment by a regional registry can never break your test.
This pattern also holds for API mocks. Return the documentation or private IP inside a field>ip key and the city inside a city key, then map the two together in a separate join column rather than trying to derive one from the other. You get the visual variety a city-based list would have offered, with none of the ownership risk.
Reviewing Private IPv4 Results Before Deployment
Private IPv4 mode is the one place where the generator needs a follow-up step before you use the values in a real network. RFC 1918 ranges are not routed on the public Internet, but they are also not globally unique. The same 192.168.1.10 address can exist on thousands of unrelated networks at the same time, and your home router, office LAN, lab VLAN, VPN tunnel, and Docker bridge may already be using the exact value the generator just produced.
A simple arithmetic check can frame the scope. The usable host count for any IPv4 CIDR block is given by 2^(32 - prefix) - 2, so a /24 block contains 2^(32-24) - 2 = 2^8 - 2 = 256 - 2 = 254 usable hosts. The 10.0.0.0/8 block alone therefore holds roughly 16.7 million usable hosts, and the 172.16.0.0/12 and 192.168.0.0/16 blocks add millions more, which is why collisions are easy to hit by accident.
Run a quick review before assigning any generated private value: check it against your DHCP scope, your subnet calculator, your VPN configuration, and any container or VM bridge that already advertises a default range. If the address lands inside an existing subnet, pick another value or shift to a documentation IPv4 block, which carries no risk of collision because it is never used on a real network.
What the Tool Will Not Do
The generator intentionally stays narrow. It does not produce arbitrary public IPv4 targets, it does not tag results with a country or city pulled from a geolocation database, and it does not verify that a private value is free on your specific LAN. Generation happens in your browser and the tool does not contact or reserve any address. Treat the output as raw sample data, then layer your own city, country, and label fields on top, and run the private values through your own address-management process before they go anywhere near production.
That narrow scope is what makes it safe to share in a public repo, paste into a customer-facing slide, or drop into a recorded walkthrough. Every address you generate is one that the IANA registry and the underlying RFC explicitly set aside for the purpose you are using it for, so the address itself cannot surprise you or anyone reading along.
Related reading: Generate Random Letter in Excel: Complete Guide.
Related reading: How to Choose the Right Random Name Picker Wheel Approach.