Sample addresses for fixtures, firewall documentation and log examples, including the RFC 1918 private ranges that never route on the public internet.
An IPv4 address is 32 bits, written as four decimal octets separated by dots, the dotted-quad notation you already recognise. Each octet carries eight bits, so every position is legal from 0 to 255, and the whole space is 2^32: 4,294,967,296 addresses, fewer than there are people on the planet. That scarcity is why so much of the range has been carved into special-purpose blocks instead of being handed out to networks.
The generator on this page draws each octet independently. In its default public mode the first octet lands between 1 and 223 and the last between 1 and 254, which keeps output clear of the 0.0.0.0/8 block, clear of multicast, and off the two addresses every /24 reserves for itself.
Two formatting traps are worth knowing before you paste output anywhere. A leading zero is not decoration: the classic C function inet_aton reads 010 as octal, so 192.168.010.1 resolves to 192.168.8.1, while the stricter inet_pton rejects the string outright. Python's ipaddress module was changed in 2021 to reject leading zeros for exactly that reason. Keep octets unpadded, and treat a padded address as a parser-confusion risk rather than a cosmetic quirk. The other trap is sorting: addresses are not numbers to a string comparison, so 10.0.0.9 lands after 10.0.0.10 unless you sort on the parsed value.
RFC 5737, published in January 2010, sets aside three IPv4 /24 blocks purely so that written examples cannot point at somebody's equipment: 192.0.2.0/24 (TEST-NET-1), 198.51.100.0/24 (TEST-NET-2) and 203.0.113.0/24 (TEST-NET-3). They are not routed across the public internet, no operator is assigned one, and network engineers recognise them on sight as "this is an example". They are the address equivalent of example.com, which RFC 2606 reserves for the same reason and which this site's random email generator uses.
Make that your default rule: anything you publish (a README, a knowledge-base article, a support ticket, a screenshot of a firewall rule, a slide) uses a documentation address. The cost of getting it wrong is not theoretical. Published examples get copied verbatim into monitoring checks, allowlists and scanner targets, and the host on the receiving end never agreed to any of it.
Each block holds 256 addresses, which is enough to write a whole topology: 192.0.2.1 for the gateway, 192.0.2.10 for the app server, 198.51.100.0/24 for the far side of a tunnel. When you need variety, generate random last octets here and prefix them yourself. The generator has no documentation-block mode, so that step is manual, and it is the cheapest safety check on this page.
RFC 1918 has defined the private IPv4 ranges since February 1996: 10.0.0.0/8, 172.16.0.0/12, which runs from 172.16.0.0 to 172.31.255.255, not to 172.255, and 192.168.0.0/16. Together they hold roughly 17.9 million addresses, and no ISP will carry them across the public internet. Turning on the private-ranges toggle here draws from all three, with the final octet limited to 1 through 254.
Private does not mean unique, and that is where fixtures go wrong. 192.168.0.0/24 and 192.168.1.0/24 are the factory defaults on a large share of consumer routers, so a test that hard-codes 192.168.1.1 can quietly match the gateway of whoever runs the suite at home. The 172.16.0.0/12 block is heavily used by container runtimes and VPN concentrators, which is exactly why split-tunnel routes collide with home networks so often. If you want a private address unlikely to clash with anything on the tester's machine, take 10.x with two random middle octets.
One more block confuses people: 100.64.0.0/10, defined by RFC 6598 in 2012 as shared address space for carrier-grade NAT. It looks public, it is not, and a subscriber behind it cannot accept inbound connections. If your logs show 100.64 addresses, that is a carrier, not an intruder.
A random 32-bit number is not a usable address, because whole regions of the space already mean something specific. 127.0.0.0/8 is loopback, all 16.7 million of those addresses refer to the machine you are on, not just 127.0.0.1, and a packet sent to any of them never reaches a wire. Multicast is 224.0.0.0/4, covering 224.0.0.0 through 239.255.255.255, and its lowest addresses are link-local control channels: 224.0.0.1 means all hosts on this subnet, 224.0.0.2 all routers. 169.254.0.0/16 is link-local, assigned by a host to itself when DHCP does not answer, so seeing one in a log is a diagnosis rather than a coincidence.
Then the edges. 255.255.255.255 is the limited broadcast address, which routers never forward, and every subnet also has its own directed broadcast where the host bits are all ones, 192.0.2.255 in a /24. 0.0.0.0/8 means "this network", and 0.0.0.0 is the wildcard you bind a server to rather than a destination you send to. 240.0.0.0/4 is still reserved.
IANA keeps the consolidated list in the special-purpose address registries described by RFC 6890; check it before assuming a block is fair game. The generator here caps the first octet at 223, which sidesteps multicast and reserved space by construction.
CIDR notation replaced class A/B/C thinking in the 1990s and was consolidated in RFC 4632 in 2006. The number after the slash is how many leading bits are fixed as the network part, so a /24 fixes 24 bits and leaves 8 for hosts. Eight host bits give 2^8, or 256 addresses, but only 254 usable hosts: the all-zeros host address names the network itself, and the all-ones host address is that subnet's directed broadcast. In 192.0.2.0/24 that means .0 and .255 are spoken for while .1 through .254 are assignable, which is why this generator never puts 0 or 255 in the final octet.
The subtraction of two is the part people get wrong when sizing a subnet. A /25 gives 126 hosts, a /26 gives 62, a /27 gives 30, a /28 gives 14, a /29 gives 6 and a /30 gives 2, the classic point-to-point link. RFC 3021, from December 2000, then allows a /31 on point-to-point links, where both addresses are usable because a link with exactly two endpoints has no need for a broadcast. A /32 is a single host, the form you see in routing tables and firewall rules. Masks say the same thing the long way: /24 is 255.255.255.0, /26 is 255.255.255.192.
An IPv6 address is 128 bits written as eight groups of four hexadecimal digits separated by colons, 2001:0db8:0000:0000:0000:ff00:0042:8329 in full. Two shortenings are allowed. Leading zeros inside a group may be dropped, and a run of consecutive all-zero groups may be replaced by a double colon. That double colon may appear only once in an address, because a second one would make expansion ambiguous: there would be no way to tell how many zero groups belong to each gap.
The special ranges come up constantly. ::1 is loopback, the v6 counterpart of 127.0.0.1. :: alone is the unspecified address. fe80::/10 is link-local, and every IPv6 interface has one whether you configured it or not. ff00::/8 is multicast; IPv6 has no broadcast at all, having replaced it with multicast groups. fc00::/7 is unique local address space from RFC 4193, though in practice you generate inside fd00::/8 and are meant to pick a random 40-bit global ID so that merged networks do not collide. 2001:db8::/32, reserved by RFC 3849 in 2004, is the documentation prefix, the v6 equivalent of the TEST-NET blocks, and the only prefix belonging in a public example. This generator emits the fully expanded eight-group form, uncompressed.
Two strings can spell the same IPv6 address, which becomes a problem the moment anything compares addresses as text. RFC 5952, published in August 2010, fixes one canonical spelling. Suppress leading zeros in every field, so 0db8 becomes db8. Use the double colon to shorten the longest run of consecutive zero fields. Do not use it for a single zero field, write the 0, because the shortening saves nothing and costs clarity. When two zero runs are the same length, compress the first. Write hexadecimal letters in lowercase. Under those rules 2001:0DB8:0000:0000:0000:FF00:0042:8329 has exactly one canonical form: 2001:db8::ff00:42:8329.
This matters for anything treating an address as a key: log deduplication, allowlists, rate-limit buckets, cache entries, uniqueness constraints. Compare parsed bytes rather than strings, or normalise on the way in, because one host can otherwise appear as several distinct entries.
Two conventions travel with it. In a URL an IPv6 literal goes inside square brackets so the colons do not fight the port separator, https://[2001:db8::1]:8443/, a rule that comes from RFC 3986. A link-local address often carries a zone identifier too, written fe80::1%eth0. The output here is valid but not canonical, so run it through a parser if canonical form matters.
Here is what these addresses are genuinely good for. Test fixtures and seed data, where you need a hundred plausible values. Log samples for a parser you are writing, since real logs often cannot be shared. Firewall and ACL rule drafting, where you want the shape of the rule before the real addresses exist. Teaching subnetting, where a fresh random address per exercise stops students memorising answers. Filling example configuration files, screenshots and support articles, with documentation-block addresses, per the rule above.
Here is what they cannot do. A generated address carries no information about whether it is routable: whether a prefix is announced at all is a fact about regional internet registries and live BGP announcements, not about the digits. Geolocation is the same story, city and country come from commercial databases built on registry records, latency measurement and self-reported feeds, all of which sit outside the address itself. A random address therefore cannot simulate a country.
Two smaller cautions. Random draws collide, so ask for 200 addresses and duplicates are unlikely but not impossible; deduplicate if uniqueness is a test requirement. And an IP address is not always anonymous data: European courts have treated a dynamic IP as personal data in some circumstances, which is a reason to generate fixtures rather than copy production logs.
Generating one is harmless; connecting to one is not the same act. An address drawn in public mode almost certainly belongs to a real organisation, so pinging, port-scanning or load-testing it can breach your provider's acceptable use policy and, in several jurisdictions, computer-misuse law. Point tests at your own hosts or a lab you control.
No, the toggle covers IPv4 only, because IPv6 has no direct equivalent of the RFC 1918 ranges. The closest thing is unique local addressing: pick a prefix inside fd00::/8 with a randomly chosen 40-bit global ID, as RFC 4193 asks, so two merged networks do not collide. For anything published, use 2001:db8::/32 instead.
Up to 200 per run, ten by default, one per line so the block pastes straight into a fixture file or a spreadsheet column. Everything runs in your browser: no address is generated on a server, none is logged, and nothing is stored between visits. Close the tab and the output is gone.
Because each of the eight fields is drawn independently across the full 0 to ffff range, a single zero field turns up roughly once in 65,536 draws and runs of two or more essentially never. Real allocations are full of zeros, a typical /64 subnet leaves whole fields empty, so write compressed examples by hand.
Your laptop holds a private address handed out by your router, usually something in 192.168.0.0/16, while websites see the public address on the router's internet side. Network address translation rewrites the source address on the way out and reverses it on the way back. If your carrier uses carrier-grade NAT, that public address is shared with other subscribers.
Same information, two notations. The prefix length counts the leading bits that identify the network; the mask writes those bits out as a dotted quad of ones followed by zeros. /24 and 255.255.255.0 are the same statement, as are /22 and 255.255.252.0. Under CIDR the ones must be contiguous, so a mask like 255.0.255.0 is invalid.
Not directly. The options here are version, count and the private-ranges toggle, with no field for a prefix. The practical workaround is to generate a batch, then replace the leading octets with the network you want: take the last octet of each line and prefix it with 192.0.2 for a documentation /24, or with your own lab prefix.
Parsers accept either case, and comparisons should be case-insensitive, but output should be lowercase: that is what RFC 5952 specifies, and mixed-case spellings of one address are a common source of duplicate log entries. Only the digits a to f have a case at all, so addresses made of 0 to 9 look identical either way.