IP Validator (v4 and v6)

IP address validation: IPv4, IPv6 and why it matters

An IP address is the numerical label assigned to every device that talks on a network. Two formats coexist on the modern Internet: IPv4, the 32-bit format introduced in 1981 (RFC 791), and IPv6, the 128-bit successor standardised in 1998 (RFC 2460, updated by RFC 8200). Validating an address means confirming it is syntactically well-formed before using it in firewall rules, allowlists, geolocation lookups, log parsers or security audits.

Validation is not the same as reachability or ownership. A string can be a perfectly valid IP and still belong to a private range, a reserved block or a non-existent host. A robust application combines syntax validation with semantic checks (is it routable? is it on my allowlist? is it inside a CIDR block?).

IPv4 anatomy

IPv4 uses four octets separated by dots. Each octet is a decimal number from 0 to 255, occupying 8 bits — a total of 32 bits, giving roughly 4.29 billion theoretical addresses. The 2011 IANA pool exhaustion forced the regional registries (RIRs) to gradually allocate the last blocks, and IPv4 transfers became a paid market.

A naive regex such as ^(\d{1,3}\.){3}\d{1,3}$ catches the shape but accepts 999.999.999.999. A proper validator also confirms each octet is in 0-255. Be aware of unusual representations: leading zeros (192.168.001.001) can be interpreted as octal by libc; hexadecimal and shorthand notation (0xC0.0xA8.1.1 or 192.168.257) are accepted by inet_aton but rejected by stricter parsers — historically a source of SSRF bypasses.

IPv6 anatomy and shorthand

IPv6 uses eight groups of four hexadecimal digits (0000-FFFF) separated by colons, 128 bits total — 2^128 addresses, about 340 undecillion. Two compression rules are allowed: leading zeros inside a group may be omitted (2001:db8:0:0:0:0:0:1 -> 2001:db8:0:0:0:0:0:1), and one run of consecutive all-zero groups may be replaced by a double colon :: (so the example becomes 2001:db8::1). The :: can appear only once per address to keep parsing unambiguous.

A complete IPv6 regex is notoriously hard to write because of the compression rules; in production prefer a library. In Node.js use net.isIP(addr) which returns 0 for invalid, 4 for IPv4 and 6 for IPv6. Other handy libraries are ip-regex, is-ip, ipaddr.js and the Python ipaddress stdlib module.

Reserved and special ranges

Knowing the reserved blocks is essential to avoid SSRF, to write meaningful firewall rules and to interpret logs:

• Private (RFC 1918): 10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16.
• CGNAT (RFC 6598): 100.64.0.0/10 — used by carriers between subscriber and public Internet.
• Loopback: 127.0.0.0/8 (IPv4) and ::1/128 (IPv6).
• Link-local: 169.254.0.0/16 (IPv4 APIPA) and fe80::/10 (IPv6).
• Multicast: 224.0.0.0/4 (IPv4) and ff00::/8 (IPv6).
• Broadcast: 255.255.255.255 (no equivalent in IPv6 — replaced by multicast).
• Documentation: 192.0.2.0/24, 198.51.100.0/24, 203.0.113.0/24, 2001:db8::/32.

CIDR, dual-stack and tooling

CIDR (Classless Inter-Domain Routing) notation appends a slash and prefix length to express a block: 192.168.1.0/24 covers 256 addresses, 2001:db8::/32 covers an enormous IPv6 block. Most modern networks run dual-stack, exposing both an IPv4 and an IPv6 address on the same interface. Useful tools: ipinfo.io and ipapi.co for geolocation, whois and rdap.org for ownership, nslookup / dig for DNS lookups, Wireshark for packet inspection.

FAQ

Are IPv4 and IPv6 the same family?

No. They are distinct address families with different sizes, syntax and routing semantics. A device on a dual-stack network has one of each and they are not interchangeable in firewall rules or allowlists.

Is CIDR notation accepted as a valid IP?

CIDR (192.168.1.0/24) is a block, not a single host. A strict IP validator rejects it; a CIDR-aware validator accepts the form and exposes the network address and prefix separately.

Is 0.0.0.0 a valid IP?

Syntactically yes. Semantically it is a wildcard meaning "all interfaces" when binding a server and "no specific destination" when used as a source — most validators accept it, most allowlists do not.

Why should I reject private IPs server-side?

If your backend fetches user-supplied URLs (webhooks, image proxies, link previews), allowing private IPs lets an attacker target your internal services — the classic SSRF vector. Always validate, resolve and re-check the resolved address against the reserved-range list.