IPv6 Address Compressor / Expander

Introduction:

IPv6 addresses often move between logs, DNS zones, firewall rules, ticket comments, cloud consoles, and command output. The same 128-bit value can be written in several legal ways, so a copied address may look unfamiliar even when nothing about the destination changed.

Text normalization matters because IPv6 shorthand hides structure. The address is divided into eight 16-bit groups called hextets, but leading zeros may be suppressed and one continuous run of zero hextets may collapse to ::. A compact form is good for runbooks and command lines; the expanded form is better when a reviewer must count groups, split prefix bits, or build a reverse DNS name.

Several suffixes and mixed forms carry context around the address value. CIDR prefixes describe the leftmost network bits, zone identifiers name a local scope such as an interface, and an IPv4 dotted tail shows the final 32 bits in decimal. None of those details proves the address is assigned or reachable, but losing them can make a troubleshooting note or access-control rule misleading.

Canonical text has a job beyond neatness. RFC 5952-style compression chooses a predictable short spelling, while expansion exposes every hextet for auditing. Prefixes, zones, and embedded IPv4 tails add context around the 128-bit value, so they should be reviewed deliberately instead of stripped away during cleanup.

Formatting still has limits. A syntactically valid address may be documentation-only, private-style unique local, link-local, multicast, or simply unused. Text normalization is a reliable starting point for review, not proof that a host exists, a route works, or a firewall rule is safe.

How to Use This Tool:

Use the formatter for one address at a time, then choose the result view that matches the job: short copy text, full hextet review, reverse DNS preparation, or bit-level checking.

1. Paste a single value into IPv6 address. Accepted examples include 2001:db8::1/64, fe80::1%en0, and ::ffff:192.0.2.128.
2. Keep a CIDR suffix when the source includes one. Valid prefixes are /0 through /128, and the Prefix length row should show the preserved number.
3. For scoped values, place the zone before the prefix, as in fe80::1%en0/64. The Zone ID row and zone badge should keep that local scope text.
4. Open Advanced when display choices matter. Display hex case changes lowercase or uppercase output, Show IPv4 dotted tail makes the final 32 bits easier to compare in mixed-stack notes, and Binary grouping changes only the spacing in Binary Blocks.
5. Read Compressed form for the copy-friendly address and Expanded form for all eight padded hextets. Check Address Details before relying on the type label, reverse name, prefix, zone, or fixed /64 split.
6. Use Hextet Breakdown when a particular group position matters, and use Binary Blocks when the question is about byte, nibble, or bit boundaries.
7. If the address does not validate, look for a second ::, a hextet longer than four hex digits, an IPv4 octet outside 0 to 255, or a prefix outside the allowed range.

Treat warnings as review blockers. Extra pasted lines, bad prefix suffixes, and empty zone markers can leave the base address readable while the surrounding context is still unsafe to copy.

Interpreting Results:

A valid result means the input could be parsed into one IPv6 address value after optional prefix, zone, and dotted-tail text were separated. It does not confirm assignment, DNS, routing, reachability, or policy.

The type label is a helpful first check, not a registry lookup. Use the expanded address, warnings, prefix row, and source system together before deciding that two strings are equivalent or safe to deploy.

Technical Details:

IPv6 text representation starts from a fixed address size: 128 bits divided into eight hexadecimal hextets. RFC 4291 allows several valid spellings, including omitted leading zeros, one double-colon abbreviation for zero groups, CIDR-style prefix suffixes, and mixed IPv6 plus IPv4 notation for the final 32 bits.

Canonical display rules narrow those choices so repeated reviews produce the same text. RFC 5952 recommends lowercase hexadecimal, no leading zeros inside a hextet, no compression of a single zero hextet, and compression of the longest all-zero run. When two zero runs are the same length, the leftmost run is the conventional choice.

Formula Core:

The basic address size comes from eight 16-bit hextets.

For dotted IPv4 tails, each pair of decimal octets is packed into one 16-bit hextet.

In ::ffff:192.0.2.128, the octets 192 and 0 become decimal 49152, or c000. The octets 2 and 128 become decimal 640, or 0280.

Transformation Core:

Reverse DNS is nibble-based rather than hextet-based. The expanded hexadecimal string is split into 32 individual hex digits, reversed from low order to high order, dotted, and suffixed for the IPv6 reverse tree.

The fixed /64 network and interface split is a hextet review aid. The entered Prefix length remains the prefix fact to use for subnet records, point-to-point links, or access-control documentation.

Limitations and Privacy Notes:

This formatter checks address syntax and derives text views. It does not query DNS, test reachability, check route tables, or verify that an address belongs to a particular organization.

• A Global label means no listed special pattern matched; it is not proof of public routing.
• Parsing runs in the browser after the page loads, and export files are prepared from the current result view.
• Non-default inputs can appear in the page address through shareable parameters, so avoid sending a copied page link when an infrastructure address should stay private.

Worked Examples:

Documentation address in a ticket. Enter 2001:0db8:0000:0000:0000:ff00:0042:8329. Compressed form becomes 2001:db8::ff00:42:8329, Expanded form stays visible as eight padded hextets, and Type reads Documentation. That label is a useful stop sign when a sample address appears in production notes.

Scoped link-local value. Enter fe80::1%en0/64. Zone ID shows en0, Prefix length shows 64, and Expanded form becomes fe80:0000:0000:0000:0000:0000:0000:0001. Keep the zone with the note because the same address text can exist on more than one interface.

Mixed IPv4 and IPv6 troubleshooting. Enter ::ffff:192.0.2.128. The dotted tail maps to hextets c000 and 0280, and Type reads IPv4-mapped. Turning on Show IPv4 dotted tail keeps the embedded IPv4 value recognizable while the hextet form remains available for comparison.

Out-of-range prefix recovery. Entering 2001:db8::1/129 can still normalize the base address, but a warning identifies the invalid prefix. Correct the suffix to a value from /0 through /128 before using Prefix length in subnet documentation.

Common Mistakes:

FAQ:

Glossary:

Hextet

One 16-bit IPv6 group written as hexadecimal text.

Compressed form

The short IPv6 spelling after leading zeros and one eligible zero run are removed.

Expanded form

The eight-hextet IPv6 spelling with four hex digits in every group.

Prefix length

The CIDR number after / that counts network-prefix bits from the left.

Zone identifier

Local scope text after %, commonly used with link-local addresses.

Reverse name

The nibble-reversed ip6.arpa name used for IPv6 PTR lookups.

References:

• RFC 4291: IP Version 6 Addressing Architecture, RFC Editor, February 2006.
• RFC 5952: A Recommendation for IPv6 Address Text Representation, RFC Editor, August 2010.
• RFC 4007: IPv6 Scoped Address Architecture, RFC Editor, March 2005.
• RFC 3596: DNS Extensions to Support IP Version 6, RFC Editor, October 2003.
• IANA IPv6 Special-Purpose Address Space, IANA.
• How to show IP addresses with ip address, Simplified Guide.