BrowserTools
Advertisement
Home / Networking / IPv6 Expander & Compressor

IPv6 Expander & Compressor

Expand any IPv6 address to its full 8-group form or compress it to the RFC 5952 canonical form, locally in your browser.

Loading IPv6 Expander & Compressor… If nothing happens, please enable JavaScript.

An IPv6 address is a 128-bit number, normally written as eight groups of four hexadecimal digits separated by colons, for example 2001:0db8:0000:0000:0000:0000:0000:0001. Because that full form is long and full of zeros, IPv6 allows two shorthand rules: leading zeros within a group may be dropped, and one run of consecutive all-zero groups may be replaced by a double colon. The same address can therefore be written compactly as 2001:db8::1. The trouble is that a single address has many valid textual representations, which makes addresses hard to compare by eye, error-prone to type into firewall rules, and inconsistent across logs and config files.

Frequently asked questions

Is the address I enter sent to a server?
No. All validation and conversion run entirely in your browser in plain TypeScript. The IPv6 address you type is never uploaded, transmitted, or stored anywhere. The tool works fully offline once the page has loaded, so it is safe to use with internal or private addresses.
What is the difference between expanded and compressed IPv6?
The expanded form shows all eight groups with every leading zero, for example 2001:0db8:0000:0000:0000:0000:0000:0001. The compressed form applies the two shorthand rules, dropping leading zeros and collapsing the longest run of zero groups into ::, giving 2001:db8::1. Both represent the exact same 128-bit address; they are just different ways of writing it.
What does RFC 5952 require for the canonical form?
RFC 5952 fixes a single preferred spelling so addresses are consistent. It requires lowercase hex digits, removal of all leading zeros in each group, use of :: to shorten the longest run of consecutive zero groups, and that :: never be used for a single zero group. When two zero runs are equally long, the leftmost one is shortened. This tool follows all of those rules.
Why can :: appear only once in an address?
The double colon means fill the gap with as many zero groups as needed to reach eight groups total. If :: appeared twice, the address would be ambiguous because there would be no way to know how many zero groups belong to each gap. The standard therefore permits at most one :: per address, and this tool rejects input that contains more.
Can I paste an address with brackets or a zone id?
Yes. The parser strips surrounding square brackets such as [2001:db8::1], which are how IPv6 addresses appear in URLs, and it removes a trailing zone identifier such as %eth0 used for link-local addresses. The conversion is then performed on the underlying address.
Does it handle IPv4-mapped addresses like ::ffff:192.168.0.1?
Yes. An embedded IPv4 suffix in dotted-decimal form is converted into the two equivalent 16-bit hexadecimal groups before expansion and compression. So ::ffff:192.168.0.1 expands to 0000:0000:0000:0000:0000:ffff:c0a8:0001 and compresses back to ::ffff:c0a8:1 in pure-hex canonical form.
What counts as an invalid IPv6 address here?
The tool reports an error when an address has the wrong number of groups, contains more than one ::, has a group with more than four hex digits or a value out of range, includes characters that are not valid hex or separators, or uses :: where it would not stand for at least one zero group. The message explains which rule was broken.
Why does my address come back in lowercase?
RFC 5952 specifies lowercase letters for the hexadecimal digits a through f in the canonical form. Uppercase is technically valid input and parses fine, but the tool normalises the output to lowercase so the result matches the standard and stays consistent across tools and logs.

About IPv6 Expander & Compressor

This tool converts in both directions. Give it any valid IPv6 address in any notation and it produces the fully expanded form, all eight groups padded to four digits with every zero shown, and the compressed canonical form defined by RFC 5952. The expanded form is ideal when you need an unambiguous value for exact string matching, for splitting an address into its network and interface halves, or for teaching how the address is structured. The compressed form is the shortest correct representation and is what you should store and display, because RFC 5952 removes the ambiguity by fixing exactly one canonical spelling per address.

All parsing and conversion happen in plain TypeScript running locally in your browser. Nothing you enter is uploaded, transmitted, or logged, so you can safely inspect internal addresses, prefixes, and host identifiers. The parser validates its input and reports a clear error for problems such as too many groups, more than one double colon, out-of-range values, or invalid characters. It also understands a few real-world conveniences: surrounding square brackets as used in URLs, a trailing zone identifier such as %eth0, and an embedded IPv4 suffix like ::ffff:192.168.0.1, which it converts into the equivalent hexadecimal groups before expanding or compressing.

Why one address had so many spellings

When IPv6 was designed, the goal was a vast address space of 128 bits, enough for roughly 340 undecillion addresses. Writing such a number in full is unwieldy, so the designers added shorthand: drop leading zeros in each group, and collapse a run of zero groups into a double colon. These rules made addresses far more readable, but they introduced a subtle problem. A single address could now be written in many equally valid ways, differing in where the :: was placed, whether zeros were padded, and whether letters were upper or lower case.

That flexibility caused real operational headaches. Logs from two systems could record the same host with different spellings, access-control lists could miss a match because of a casing difference, and simple string comparison could not be trusted to tell whether two addresses were the same. Network engineers wasted time chasing bugs that were really just two spellings of one address failing to compare as equal.

RFC 5952, published in 2010, fixed this by defining a recommended canonical representation. It mandated lowercase hex, no leading zeros, shortening the longest zero run with ::, never using :: for a single zero group, and a tie-break rule favouring the leftmost run. With one official spelling per address, tools could finally normalise and compare IPv6 addresses reliably. This converter implements that exact algorithm, which is why its compressed output is safe to use as a canonical key.

Advertisement
Advertisement
Advertisement