IP Address Validator

Validate and classify IPv4 and IPv6 addresses.

IP Address

Valid IPv4

Private address

IPv4 and IPv6 addresses

An IPv4 address is four decimal octets (0–255) separated by dots, like 192.168.1.1, while IPv6 uses eight groups of up to four hex digits separated by colons, with ::as a one-time shorthand for consecutive zero groups — and it also accepts IPv4-mapped forms like ::ffff:192.168.1.1 and zone IDs (fe80::1%eth0). This validator checks the syntax of both and classifies the address — for IPv4: private, loopback, link-local (APIPA), CGNAT, broadcast, multicast, and reserved ranges; for IPv6: loopback, link-local, unique-local (ULA), multicast, IPv4-mapped, and global unicast. Everything is evaluated locally in your browser.

Built and maintained by Meet Shah · Last updated 24 July 2026

What this tool is used for

Checking whether a string from a log or a form is a well-formed address at all.
Classifying an address as private, loopback or public during an investigation.
Validating a list of addresses before importing them into a firewall rule.
Distinguishing an IPv4 from an IPv6 address in mixed input.
Confirming that a rejection is a format problem rather than a routing one.

Frequently Asked Questions

What makes an IPv4 address valid?: Four decimal octets, each 0-255, separated by dots. The subtleties: leading zeros are ambiguous (some parsers read 010 as octal 8), and inet_aton accepts short forms like 127.1 that most validators should reject.
Why is IPv6 validation harder?: Because of :: compression, which may appear at most ONCE, plus optional embedded IPv4 (::ffff:192.0.2.1) and zone indices (%eth0). RFC 5952 also mandates lowercase and compressing the longest zero run.
Does a valid address mean it is reachable?: No — validation is syntax only. The address may be unassigned, unrouted, reserved, or behind a firewall. Reachability requires an actual network probe, which a browser cannot perform.
Which ranges should I treat specially?: The private RFC 1918 blocks, 127.0.0.0/8 loopback, 169.254.0.0/16 link-local, and 100.64.0.0/10 carrier-grade NAT. SSRF protection must reject all of these, and the check must happen AFTER DNS resolution.
Why do obfuscated addresses matter?: Because 2130706433, 0x7f000001 and 127.1 all resolve to localhost. Filters that only string-match "127.0.0.1" are trivially bypassed — this is a well-known SSRF technique, not a theoretical one.
Why should leading zeros be rejected?: Because some libraries read `010` as octal 8 and others as decimal 10, so the same string resolves to two different hosts. That ambiguity has been the basis of a long line of SSRF filter bypasses.
What is an IPv4-mapped IPv6 address?: The `::ffff:192.0.2.1` form, which represents an IPv4 address inside IPv6. It is valid in both notations, so a validator accepting only one of the two rejects an address the network stack handles fine.
Does a hostname that looks like an IP need different handling?: Yes. `1.2.3.4.example.com` is a hostname, and `0x7f.1` is a valid but obscure IPv4 form. Deciding by shape rather than by parsing is where filters get this wrong.

Common errors and gotchas

Treating leading zeros as decimal, when some resolvers read them as octal and reach a different host.
Assuming IPv6 has one form. Compression with a double colon means the same address has several spellings.
Reading well-formed as reachable, which says nothing about DNS, routing or whether anything answers.
Overlooking IPv4-mapped IPv6 addresses, which are valid and easy to mis-classify.
Validating an address with a port or a CIDR suffix attached and getting a format error rather than a parse.