Random IP Address Generator

Two protocols, two address sizes

An IPv4 address is 32 bits, written as four numbers from 0 to 255 separated by dots. That gives about 4.3 billion possibilities, which seemed limitless when the protocol was designed and was exhausted in practice years ago. IPv6 uses 128 bits, written as eight groups of four hexadecimal digits, and the space it provides is large enough that running out is not a meaningful concern.

Both are in use simultaneously, and much of the internet speaks both. Software that handles addresses generally has to handle both, which is why testing with a mixture is worthwhile rather than assuming the four-dotted-numbers shape.

Reserved ranges exist so examples are safe

It is tempting to invent an address for a diagram or a configuration example. The problem is that almost every plausible-looking address belongs to somebody. Published examples get copied into real configurations, scanned by automated tools, and occasionally receive genuine traffic — all aimed at an organisation that never agreed to it.

The standards bodies solved this by setting aside blocks that route nowhere. RFC 5737 reserves three IPv4 ranges for documentation, and RFC 3849 reserves an IPv6 prefix for the same purpose. An address from those blocks is unambiguously an example. Anyone who recognises the range knows immediately that it is not a real host, and no traffic can reach one by accident.

This is why the documentation option is the default here. If a value will appear in anything published — a tutorial, a screenshot, a sample configuration file — it belongs in a documentation range.

Private addresses and why your router uses them

RFC 1918 reserves three IPv4 ranges for private networks. They are routable inside a local network and dropped by any router facing the public internet, which is what allows every household to use 192.168.1.1 simultaneously without conflict. Address translation at the router maps that internal address onto a single public one for outbound traffic.

Generating private addresses is useful when building fixtures for anything that reasons about network topology — firewall rules, allow-lists, monitoring configuration — because that code needs to distinguish internal from external correctly, and getting the boundaries of those three ranges right is a common source of mistakes. The 172.16.0.0/12 block in particular is often implemented incorrectly, because it covers 172.16 through 172.31 rather than the whole 172 range.

What makes address validation hard

Validating an IPv4 address looks trivial and is not. Each octet must be 0 to 255, so 256 is invalid, and leading zeroes are ambiguous because some parsers historically read them as octal — meaning 010 could be eight or ten depending on the library. Some functions accept fewer than four parts and interpret them in surprising ways.

IPv6 adds its own difficulties: the double-colon abbreviation may appear only once, groups may omit leading zeroes, and there is a hybrid notation embedding an IPv4 address at the end. Generating a spread of values and pushing them through your validator is a faster way to find the gaps than reasoning about the grammar.

Addresses are not identities

Worth stating for anyone generating addresses for a dataset: an IP address identifies a network interface at a moment in time, not a person. Home addresses are frequently reassigned, mobile networks share one address across many users, and traffic through a proxy or a VPN carries the intermediary’s address. Treating an address as a stable identifier for a user produces both technical and privacy problems.

Privacy

Addresses are generated in your browser. Your own address is never read, and nothing generated here is transmitted, stored or logged.