IPv6 Address Compressor / Expander
Normalize one IPv6 literal into canonical compressed and expanded forms with preserved prefix and zone context plus binary and reverse-DNS views.{{ summaryTitle }} · {{ summaryValue }} · {{ summaryLine }} · {{ summaryBadgeText }}
{{ summaryAnnouncement }}
| Property | Value | Review use | Copy |
|---|---|---|---|
| Correct the IPv6 input to restore normalized address rows. | |||
| {{ row.property }} | {{ row.value }} | {{ row.use }} | |
Canonical spelling
{{ canonicalGuidance }}
Prefix and scope context
{{ contextGuidance }}
Reverse DNS
{{ computation.ok ? address.reverse_pointer : 'Unavailable' }}
The pointer reverses all 32 expanded hexadecimal nibbles; it does not verify that a PTR zone or record exists.
128-bit view
{{ computation.ok ? address.binary_grouped : 'Correct the address to restore the binary view.' }}IPv6 addresses often appear in logs, firewall rules, interface output, and DNS records with different spellings. One system may show every leading zero, another may collapse a run of zero groups with ::, and a third may attach a prefix length or local zone identifier. Those strings can still refer to the same 128-bit address.
The address value contains eight 16-bit hexadecimal groups called hextets. Expanded notation shows four hex digits in every hextet. Compressed notation removes leading zeros and may replace one run of two or more all-zero hextets with ::. Canonical spelling makes text comparison predictable by choosing the longest zero run, choosing the leftmost run when lengths tie, and using lowercase hexadecimal.
| Text part | Example | Meaning |
|---|---|---|
| Address | 2001:db8::1 | The 128-bit value. |
| Prefix length | /64 | Network context from 0 through 128; it does not change the address bits. |
| Zone identifier | %en0 | Local scope context, commonly needed to disambiguate a link-local address. |
| Dotted tail | ::ffff:192.0.2.128 | An IPv4-style view of the final 32 bits. |
Normalization helps when comparing access lists, checking copied addresses, documenting interfaces, or preparing a reverse-DNS name. It does not say that an address is assigned, reachable, globally routable, or owned by a particular organization. Prefix and zone text must also be preserved when the surrounding command or configuration depends on them.
Address-type labels come from recognizable bit prefixes. They are useful clues for loopback, link-local, unique-local, multicast, documentation, transition, and mapped forms, but they are not a complete allocation or route lookup.
How to Use This Tool:
Normalize one literal at a time and keep any prefix or zone context attached to it.
- Enter one IPv6 address, optionally followed by a zone identifier and prefix length, such as
fe80::1%en0/64. Extra nonblank lines are ignored with a warning. - Choose lowercase or uppercase display text, select the binary grouping width, and enable Show dotted IPv4 tail only when the final 32 bits need an IPv4-style view.
- Copy the compressed form for ordinary use and check the canonical form for comparison. Use the expanded, hextet, binary, or reverse-pointer views when reviewing exact bits or DNS preparation.
Interpreting Results:
Compressed with context follows the selected case and dotted-tail preference while retaining the entered zone and prefix. RFC 5952 canonical is always lowercase hexadecimal and excludes that surrounding context, making it the better field for stable address-text comparison.
- The canonical expanded form contains eight hextets and therefore represents exactly 128 bits; dotted-tail display is an alternate view of the final two.
- The fixed first-64/last-64 split is a reading aid, not a replacement for the entered prefix length.
- The dotted tail is another spelling of the low-order 32 bits; it does not convert the whole value into IPv4.
- The reverse pointer is a prepared
ip6.arpaname, not proof that a PTR record exists.
A syntax-valid result confirms only that the literal can be parsed under the accepted rules. Check live interface, route, firewall, and DNS state separately when the address will be used operationally.
Technical Details:
IPv6 normalization first separates the optional CIDR suffix and zone identifier from the address. A dotted IPv4 tail is packed into two hextets, :: is expanded to the missing number of zero hextets, and every hextet is parsed as an unsigned 16-bit value.
Formula Core:
Eight hextets establish the fixed address width. The display settings never change these 128 bits.
Each pair of dotted decimal octets becomes one hextet. Both octets must be whole numbers from 0 through 255.
Transformation Core:
| Stage | Rule | Derived view |
|---|---|---|
| Context split | Accept at most one /0 to /128 suffix and one zone identifier after %. | Prefix and zone remain available without entering the 128-bit value. |
| Dotted-tail packing | Convert four decimal octets into the final two hextets. | Mixed notation and hexadecimal notation resolve to the same bits. |
| Expansion | Allow only one ::; it must replace at least one missing hextet. | Eight four-digit hexadecimal groups. |
| Canonical compression | Remove leading zeros and collapse the leftmost longest zero run only when it spans at least two hextets. | Lowercase RFC 5952 text. |
| Reverse DNS | Remove colons from the expanded form, reverse all 32 hexadecimal nibbles, insert dots, and append ip6.arpa. | A full-address reverse pointer for PTR preparation. |
Rule Core:
Classification follows the first matching pattern in the table. The final fallback is deliberately Other / reserved; an unmatched value is not assumed to be global unicast.
| Label | Pattern | Boundary |
|---|---|---|
| Unspecified | :: | Exactly ::/128. |
| Loopback | ::1 | Exactly ::1/128. |
| IPv4-mapped | ::ffff:0:0/96 | First 80 bits zero, then ffff. |
| Multicast | ff00::/8 | First byte equals ff. |
| Link-local | fe80::/10 | First hextet from fe80 through febf. |
| Unique local | fc00::/7 | First hextet from fc00 through fdff. |
| 6to4 | 2002::/16 | First hextet equals 2002. |
| Teredo | 2001:0000::/32 | First two hextets are 2001:0000. |
| Documentation | 2001:db8::/32 | First two hextets are 2001:0db8. |
| Global unicast | 2000::/3 | Checked after the listed special patterns. |
| Other / reserved | No listed pattern | No allocation or reachability conclusion is implied. |
Binary output concatenates all eight hextets into a 128-character bit string and inserts spaces every 1, 4, 8, or 16 bits for display. Grouping changes readability only.
Limitations and Privacy Notes:
Address parsing and derived notation are produced in the browser without a DNS or reachability lookup. The entered literal is syntax data, but copied text, screenshots, and downloaded ledgers can still disclose internal addressing.
- Only the first nonblank input line is normalized; additional lines produce a warning.
- Zone identifiers accept letters, digits, dot, underscore, and hyphen up to 32 characters.
- Classification covers the exact built-in patterns only and is not a complete IANA allocation test.
- No PTR query, route check, interface lookup, or ownership lookup is performed.
Worked Examples:
Equal zero runs
2001:db8:0:0:1:0:0:1 contains two zero runs of length two. Canonical compression chooses the leftmost run, producing 2001:db8::1:0:0:1.
IPv4-mapped address
::ffff:192.0.2.128 expands to 0000:0000:0000:0000:0000:ffff:c000:0280. Uppercase and dotted-tail display can show ::FFFF:192.0.2.128, while the canonical comparison value remains ::ffff:c000:280.
References:
- RFC 4291: IP Version 6 Addressing Architecture, IETF, February 2006.
- RFC 5952: A Recommendation for IPv6 Address Text Representation, IETF, August 2010.
- RFC 4007: IPv6 Scoped Address Architecture, IETF, March 2005.
- RFC 3596: DNS Extensions to Support IP Version 6, IETF, October 2003.
- IPv6 Special-Purpose Address Space, IANA.
- How to show IP addresses with ip address, Simplified Guide.