IP Address Inspector
Validate IPv4 and IPv6 text, normalize IPv6 notation, inspect IPv4-mapped addresses and zone identifiers, and recognize common special-purpose ranges without making ownership or geolocation claims.
Enter one address such as 192.0.2.10, 2001:db8::1, ::ffff:192.0.2.10, or fe80::1%eth0. Do not include a CIDR prefix or port.
IP Inspection Result
Classification uses a bundled set of common special-purpose ranges and chooses the most-specific matching prefix.
Enter one IPv4 or IPv6 address to validate and inspect it.
A Valid Address Can Still Be the Wrong Address
Syntax alone cannot tell you who owns an address, whether it is allocated, whether a route exists, or whether the host is reachable. Those questions require live registration, DNS, routing, or network information. Here, the address text is parsed locally and compared with a bundled set of special-purpose prefixes.
A lack of a special-purpose match should therefore be read as “nothing in this bundled list matched,” not as proof that an address is public, assigned, or safe to trust.
The Most Specific Prefix Wins
Special-purpose registries contain broad blocks with smaller assignments inside them. 192.0.0.0/24, for example, contains the more-specific 192.0.0.9/32 PCP anycast address and 192.0.0.10/32 TURN anycast address. Matching the broad /24 first would give the wrong classification, so ranges are checked from longest prefix to shortest.
“Private,” “Shared,” and “Link-Local” Are Different Categories
- RFC 1918 private IPv4 space is
10.0.0.0/8,172.16.0.0/12, and192.168.0.0/16. 100.64.0.0/10is Shared Address Space, commonly associated with carrier-grade NAT. It is not RFC 1918 private space.169.254.0.0/16andfe80::/10are link-local. They are meaningful on a local link rather than as ordinary globally routed addresses.- TEST-NET IPv4 ranges and IPv6 documentation prefixes exist so examples can avoid borrowing real production addresses.
IPv6 Text Has Many Valid Spellings
IPv6 permits leading-zero omission and :: compression. The normalized form follows RFC 5952: lowercase hexadecimal, suppressed leading zeroes, the longest eligible zero run compressed, and the first run chosen when two runs have the same length.
IPv4-mapped IPv6 addresses are shown in mixed notation such as ::ffff:192.0.2.10. RFC 5952 recommends that readable form when a well-known prefix identifies the embedded IPv4 address. The expanded line still shows all eight 16-bit groups when the raw bits are what you need to compare.
The normalization rules come from RFC 5952, while the underlying IPv6 address forms are defined by RFC 4291.
A Zone Identifier Belongs to the Local Interface Context
Text such as fe80::1%eth0 combines an IPv6 address with a host-specific zone identifier. The %eth0 part is not one of the 128 address bits; it tells the local system which zone or interface applies to a scoped address.
RFC 9844 now describes zone identifiers as a user-interface concern and completely obsoletes the older RFC 6874 URI approach. A raw operating-system form should not be assumed to be a portable URI host string. Zone names and numeric interface indexes can also differ from one machine to another.
RFC 9844 — Entering IPv6 Zone Identifiers in User Interfaces
Strict Dotted Decimal Avoids Old IPv4 Ambiguities
Each IPv4 octet is accepted only as one to three decimal digits from 0 through 255. Multi-digit values with a leading zero are rejected. Older APIs have accepted octal, hexadecimal, or shortened IPv4 forms, which can make the same text mean different things in different parsers. Strict dotted decimal avoids that ambiguity.
Special-Purpose Assignments Change Over Time
The bundled classifications are a convenience snapshot, not a replacement for the registries. When an unusual range affects routing, filtering, abuse handling, or an allowlist, compare it with IANA's live IPv4 special-purpose registry or IPv6 special-purpose registry. IANA also records whether each registered block is valid as a source or destination, forwardable, and globally reachable.