Random IP generator
Random IPv4 addresses for test fixtures, database seeds and load-test inputs. Constrain them to a block, or keep them publicly routable so geolocation lookups actually resolve.
10 addresses
175.68.26.147
118.151.129.82
48.139.153.215
135.244.94.79
96.225.74.182
92.29.157.249
101.164.36.223
91.205.78.246
61.44.93.52
166.212.39.233Use the documentation ranges for anything public
A random address is somebody's address. If it is going into a README, a blog post, a screenshot or a support ticket, use a range reserved for exactly that purpose — nobody routes them, so no real network is implicated.
| Range | Reserved by | Use for |
|---|---|---|
| 192.0.2.0/24 | RFC 5737 (TEST-NET-1) | Documentation and examples |
| 198.51.100.0/24 | RFC 5737 (TEST-NET-2) | A second distinct example network |
| 203.0.113.0/24 | RFC 5737 (TEST-NET-3) | A third distinct example network |
| 2001:db8::/32 | RFC 3849 | IPv6 documentation |
| 240.0.0.0/4 | RFC 1112 | Reserved — never routable |
Building realistic test fixtures
If you are testing geolocation behaviour, random public addresses give you a spread of countries and network operators without hand-picking them, which is usually the point — hand-picked fixtures tend to encode the author's assumptions about what the data looks like.
Constrain to a block instead when you are testing something that cares about locality: rate limiting per prefix, allow-list matching, or per-ASN quotas.
Frequently asked
- What does “publicly routable only” exclude?
- Private ranges (10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16), loopback, link-local, carrier-grade NAT, multicast, reserved space and the documentation ranges. Those addresses have no public geolocation, so a fixture built from them will not produce meaningful lookup results.
- Why does asking for public addresses inside 10.0.0.0/8 fail?
- Because it is impossible: every address in 10.0.0.0/8 is private by definition, so no address satisfies both constraints. The tool stops and says so rather than retrying forever. Clear the block or untick the option.
- Should I use these for anything other than testing?
- No. These are random draws from the address space, so they belong to real networks and real organisations. Use the RFC 5737 documentation ranges — 192.0.2.0/24, 198.51.100.0/24, 203.0.113.0/24 — for anything published, such as examples in documentation or screenshots.
- Are the addresses uniformly distributed?
- Within a block, yes. Block sizes are always powers of two and divide the 32-bit space exactly, so reducing a uniform random 32-bit value into the block introduces no bias. The values come from the browser's crypto API where available.
Doing this for thousands of addresses?
These calculators run in your browser and never send us your input. When you need geolocation, ASN and network data for addresses in bulk, the API answers in one call — no key required to try it.
curl https://api.ipaddresstoday.com/api/v1/8.8.8.8Other free tools
- Subnet calculatorNetwork and broadcast address, subnet mask, wildcard mask, usable host range and host count for any IPv4 block.
- CIDR to IP rangeConvert a CIDR block to its first and last address, or collapse an arbitrary address range into the smallest set of CIDR blocks.
- IP address converterConvert an IPv4 address between dotted-quad, decimal, hexadecimal, binary and octal.
- IPv6 expand & compressExpand an IPv6 address to its full 39-character form, or compress it to the canonical RFC 5952 short form.
- IP range generatorList every address in a CIDR block or a first–last range, ready to paste into a firewall rule or a script.