IP address version detector

Valid input returns the detected version and a stable canonical representation that is easier to compare, store, and review. Invalid address text returns a specific reason, such as an out-of-range IPv4 octet, an illegal leading zero, too many IPv6 groups, or incorrect double-colon compression. The parser is deterministic, uses no network lookup, and treats addresses strictly rather than guessing what incomplete or decorated input was intended to mean.

Identify IPv4 and IPv6 syntax precisely

IPv4 and IPv6 represent addresses in very different textual forms, and checking only for a period or colon is not enough to validate either one. This detector parses the complete string against the structural rules for both versions. IPv4 must have exactly four decimal octets separated by periods. Every octet must be between 0 and 255, must contain digits only, and must not use a leading zero. IPv6 uses eight hexadecimal groups, with colons between them, and can shorten one run of zero groups with a double colon. An IPv6 address may also end with an embedded dotted-decimal IPv4 address when the overall group count remains correct. The output says IPv4 or IPv6 only after the entire value passes validation. A value that merely resembles an address is classified as neither and includes a reason that identifies the failed rule. This makes the result appropriate for form validation, configuration checks, import cleanup, and automated tests where a loose guess could silently accept bad data.

Use canonical output for comparisons and storage

A valid IP address can have more than one textual spelling, especially in IPv6. Uppercase and lowercase hexadecimal digits represent the same values, leading zeros inside a group do not change the address, and a run of zero groups can be compressed. The canonical IPv6 result uses lowercase hexadecimal, removes unnecessary leading zeros, and compresses the longest run of two or more zero groups. If equally long runs exist, it compresses the first one. Embedded dotted-decimal IPv4 components are converted to their equivalent hexadecimal groups so the response always has one consistent IPv6 form. IPv4 is returned as four ordinary decimal octets. These normalization rules let systems compare canonical strings without confusing two spellings of the same address for two different endpoints. They are also useful when preparing logs, deduplicating configuration values, building test snapshots, or presenting an address for human review. Canonicalization does not perform DNS, geolocation, subnet analysis, or reachability testing; it changes representation only, without changing the numeric address.

Interpret rejection reasons and strict boundaries

When address text is invalid, the response reports version as neither and explains why it was rejected. Common IPv4 failures include a missing octet, a component above 255, non-decimal characters, or a leading zero that could be interpreted differently by older software. Common IPv6 failures include a group longer than four hexadecimal digits, the wrong number of expanded groups, more than one double colon, or compression that replaces no group at all. Brackets used in URL authority syntax, CIDR prefix lengths, port numbers, and zone identifiers are intentionally outside this input contract. Remove those decorations and submit only the address itself. This strict boundary keeps validation predictable across browsers, servers, and programming languages whose convenience parsers may accept different historical forms. A missing or non-string address is a request-contract error, while a supplied string with invalid address syntax is a normal detection result with a rejection reason. The algorithm has bounded work, no external state, and no network call, so repeated requests always agree. API requests cost $0.002, and the browser version can run locally.