How to Generate Random IPv4 and IPv6 Addresses

Developers and QA teams need addresses that validate as IPs but are not tied to a production customer. Designers need plausible examples in mockups. Teachers need clean samples for subnet lessons without copying live infrastructure.

• Form and API validation — confirm your UI accepts dotted-decimal or colon-hex forms
• Logs and dashboards — anonymized or synthetic source fields for screenshots
• Seed data — databases of “devices” or “sessions” that never point at real users
• Docs and tutorials — consistent examples that readers can retype

Generate samples with the IP address generator. For other opaque IDs in the same fixtures, see how UUIDs work. For numeric ranges that are not IPs, use a random number range workflow.

An IPv4 address is 32 bits, usually written as four decimal octets 0–255 separated by dots: 203.0.113.10. Early Internet documentation grouped addresses into classes A, B, and C by the leading bits. Modern routing uses CIDR prefixes, but class labels still appear in tools and textbooks.

Class-style ranges (historical lens)

• Class A — large blocks historically starting in the lower first-octet ranges (tools may sample “Class A–like” public patterns such as 1.x.x.x style examples)
• Class B — mid-size historical blocks (often illustrated around 128.x.x.x patterns in generators)
• Class C — smaller historical blocks (commonly illustrated with 192.x.x.x style public examples, distinct from private 192.168.0.0/16)

When a generator offers “Class A/B/C,” it is usually sampling within educational or demo-friendly patterns — not assigning you a real allocation from a registry. Always treat output as synthetic.

Reserved documentation ranges (for example TEST-NET blocks described in RFCs) are ideal in formal specs; a random generator is ideal when you only need “looks like an IP” quickly.

RFC 1918 defines private IPv4 space that is not routed on the public Internet. Home routers, corporate LANs, and lab VMs live here. Generating private addresses is often the safest choice for internal app demos.

• 10.0.0.0/8 — 10.0.0.0 – 10.255.255.255
• 172.16.0.0/12 — 172.16.0.0 – 172.31.255.255
• 192.168.0.0/16 — 192.168.0.0 – 192.168.255.255

When private samples help

Mock “LAN clients,” illustrate NAT diagrams, or fill device tables that should never look like public servers. Many generators include a private option so you do not accidentally paste a random public-looking address into a context where someone might try to reach it.

Still label fixtures clearly. Even private IPs can collide with a reader’s real home network if they copy your tutorial config blindly — use obvious lab subnets when writing step-by-step networking guides.

The IP address generator can target private ranges explicitly so bulk samples stay in 10/8, 172.16–31, or 192.168 space.

IPv6 uses 128 bits, written as eight groups of four hexadecimal digits separated by colons: 2001:0db8:85a3:0000:0000:8a2e:0370:7334. Leading zeros in a group may be dropped, and one contiguous run of zero groups may be compressed with ::.

Reading generated IPv6

• Full form — all groups present; easiest for parsers and teaching
• Compressed form — :: shortens zeros; only one :: per address
• Case — hex is case-insensitive; pick one style in docs to reduce noise

Documentation often uses the 2001:db8::/32 prefix reserved for examples. A random IPv6 generator may produce full random-looking 128-bit strings for UI tests; those are still synthetic. Do not assume a random IPv6 is allocated to you or safe to announce.

When you embed addresses inside JSON fixtures, keep them as strings and pretty-print with a JSON formatter. Encoding binary forms for transport is a separate concern — see how Base64 works.

Synthetic IPs shine when the field type must be “IP-shaped” but the value must not identify a real user or host you intend to contact.

• Unit tests — assert validators accept dotted IPv4 and reject 999.1.1.1
• UI snapshots — tables of sessions with source IPs
• Rate-limit logic — many distinct keys without production traffic
• Geo-IP stubs — feed a mock lookup layer with known fixtures (not live lookup of random hosts)
• Config templates — placeholder allowlists clearly marked as samples

What not to do

• Do not scan, flood, or probe addresses you generated “to see what happens”
• Do not put random public IPs into production firewall rules without review
• Do not treat a generated IP as proof of identity or as a secret

For secrets and login material, use a proper password generation workflow. For unique resource IDs, prefer UUIDs over IPs.

Choose based on the story your fixture tells.

• Private — internal apps, VPN clients, IoT-on-LAN demos, “office network” diagrams
• Public-style random — CDN edge logs, internet-facing WAF demos, “visitor IP” columns in analytics UIs
• Class filters — when a lesson or legacy form still speaks in A/B/C language
• IPv6 — dual-stack UIs, modern mobile-path examples, long-string layout tests

Bulk generation (for example up to 20 addresses) helps fill tables quickly. Copy individuals when you only need one example in a paragraph. Version badges on a good tool make IPv4 vs IPv6 obvious in a mixed list.

If you later hash or tokenize IPs for privacy demos, remember hashing is not encryption of the original value’s meaning for every threat model — keep privacy design explicit in product code, not only in sample data.

A short checklist keeps samples consistent across a team.

1. Open the free IP address generator.
2. Choose IPv4 or IPv6.
3. For IPv4, pick class-style sampling, private ranges, or general random public-style addresses as the tool allows.
4. Set how many addresses you need (up to the bulk limit).
5. Generate and confirm the format matches your validator (dots vs colons).
6. Copy one address or the full list into fixtures or docs.
7. Label samples as synthetic so nobody treats them as live inventory.

Prefer client-side tools for quick demos. For automated test suites, generate inside the test framework so CI does not depend on a website.

Related generators on Generatr include MAC address helpers and UUID tools when device and resource IDs appear next to network fields in the same mock payload.