Random IP Address Generator
Generate random IPv4 or IPv6 addresses for test data and mock configs. Filter by public or private range. Fake test values only - not real assigned hosts.
- Free, no account
- No watermark
- No usage limit
About the Random IP Address Generator
A random IP address generator gives you a batch of fake IPv4 or IPv6 addresses the second the page loads. Pick a version, set how many you want, filter by range if you care, and copy the list. It all runs in your browser, so nothing you generate is uploaded, logged, or saved.
Most generators that do this take the laziest path available: pick four numbers between 0 and 255, join them with dots, call it a day. Fine, until you ask for a public address and the thing happily hands you 127.4.9.12, which is loopback and never leaves the machine, or 10.200.5.1, which is private and never routes on the open internet. Both get labeled public, and both are wrong. The reason that stings is the addresses still look perfect, so your test passes on bad data and the real bug waits to surface in production instead.
The range filter here knows the map. Ask for public and it refuses to emit any block that would never show up on the real internet. Ask for private and you get genuine RFC 1918 space, including the one range almost everybody types wrong. That correctness is the whole reason to reach for this instead of a five-line script you threw together in a hurry.
These addresses are stand-ins, meant for seeding a test database, filling mock API responses, dressing up sample logs, or teaching someone the difference between a private and a public range. They are correctly formatted and drawn fresh every time, so you get a plausible value without inventing one yourself. If the address is going somewhere other people will read it, pick the Documentation range, which is the only one nobody can be sitting behind.
How to use
- Pick a version. IPv4 for the familiar dotted form like
203.0.113.42, or IPv6 for the long hex-and-colon form. IPv4 covers most testing. Switch to IPv6 when you are checking code that has to handle both, since plenty of parsers that eat IPv4 fine will choke on the longer format. - Set how many. The count box takes 1 to 100. A first batch is already sitting there when the page loads, so you can check the shape before committing to a bigger run.
- Choose a range. Leave it on Any for fully random across the whole space. Pick Public only to skip every private and reserved block so each address looks routable. Pick Private only to force addresses into the internal ranges (
10.x,172.16-31.x,192.168.x, orfd00::on IPv6). - Regenerate for a fresh batch with your current settings. Every click is an independent draw.
- Copy all grabs the whole list, one address per line, ready for a spreadsheet, a
.env, a seed script, or a fixture.
No sign-up, no install, and the whole thing takes about ten seconds.
What "public only" actually skips
This is exactly where the cheap generators fall down. The public internet is not "everything except 192.168." A whole pile of blocks are carved out for special jobs, and none of them belong in address data you are pretending came from the open web. When you pick Public only, the generator steers around all of them:
- Loopback (
127.x), which always means "this machine" and never travels anywhere. - Link-local (
169.254.x), the address a device assigns itself when DHCP fails. Seeing one usually means something broke. - Carrier-grade NAT (
100.64.xthrough100.127.x) and the benchmarking block (198.18.x), which look public but aren't. - Multicast and reserved (
224.xand up), which aren't normal host addresses at all. - The documentation ranges, and of course the private blocks themselves.
A generator that just rolls four dice will cheerfully call 169.254.1.1 a public address. This one won't, and that gap is the whole difference between sample data that looks plausible and sample data that is actually correct.
The private side has its own trap. RFC 1918 defines three private IPv4 blocks, and the middle one is 172.16.0.0/12. That /12 works out to a second octet of 16 through 31, not the full 0 to 255. So 172.16.5.9 and 172.31.240.1 are private, while 172.15.0.1 and 172.32.0.1 are public. It is the single most mistyped fact about private ranges, and people hardcode 172.20.x as "definitely private" while staying fuzzy on where the block actually stops. Pick Private only and every 172 address the tool produces lands inside the correct window automatically. On IPv6, private means a Unique Local Address starting with fd, which is the closest equivalent to an internal-only network.
The honest caveat about "public"
A public-looking random address is unlikely to be assigned to a live host, but it isn't guaranteed to be free. Most of the routable space is already handed out. For internal test data that never leaves your laptop, that is a non-issue, a random public address is fine and nobody will ever notice.
The moment you want to publish the address, in a manual, a blog post, a public tutorial, that changes. That is what the Documentation filter is for. It draws from 192.0.2.x, 198.51.100.x, and 203.0.113.x for IPv4 and from 2001:db8:: for IPv6, the ranges standards bodies set aside precisely so an example can never collide with somebody's real machine. Public draws deliberately skip those blocks, which is the right call for a config file and the wrong one for a tutorial, so switch the filter rather than trusting a public draw. Otherwise a made-up address in a widely read tutorial could send a few thousand readers straight to a stranger's real server.
Frequently asked questions
Are the addresses evenly random, or skewed toward some values?
Even. The numbers come from your browser's cryptographic random source, drawn so every allowed value in a range is equally likely. A naive random % 256 quietly biases the low end when the range doesn't divide cleanly, and that skew can matter if you are testing how something buckets or sorts addresses. Here the spread across each range stays clean.
Can I lock output to one specific subnet, like `192.168.5.x`?
Not directly. The filter picks across a whole class (any, public, or private), not a single subnet you name. If you need every address inside 192.168.5.x, generate a private batch and keep the ones that match, or just fix the first three octets yourself and paste random last octets after them. For repeated subnet-specific work inside code, a faker library that takes a CIDR argument is the better fit.
Could the same address show up twice in one batch?
Yes, it can, the tool draws each address independently and doesn't remove duplicates. Across the full IPv4 or IPv6 space a repeat is astronomically unlikely, but generate a large private batch, say 100 addresses all inside 192.168.x, and the odds climb enough that a quick check is worth it before you rely on uniqueness, and regenerating clears any clash you spot.
Why aren't the IPv6 addresses shortened with `::`?
The tool writes them out group by group without collapsing the longest run of zeros into ::. That is still a perfectly valid, unambiguous address, just the uncompressed style. If your test specifically exercises :: compression, you will want to compress them yourself or feed your parser both forms, since the short and long versions are supposed to be treated as the same address.
Should I just use a faker library instead?
If the addresses are minted inside your app on every test run, yes, call faker.internet.ip() or its equivalent in code so the data regenerates fresh and lives in version control as logic rather than a frozen list. This tool is built for the one-off: a quick fixture, a spreadsheet column, a demo, or letting a QA tester or a writer grab a clean batch without opening a terminal. Different jobs, and this one isn't trying to replace your test suite.
Does anything get uploaded or saved?
No. Every address is built locally in your browser and nothing leaves it, not the list, not your version choice, not the range setting. There is no account and no history. Refresh or close the tab and the current batch is gone for good, so copy what you need before you go.