IPv6 Address Compressor / Expander

Introduction:

IPv6 addresses are 128-bit interface identifiers, but people rarely write all 128 bits out in full. The same address may appear with dropped leading zeros, a double-colon zero run, uppercase or lowercase hexadecimal letters, a prefix suffix, or the last 32 bits written as familiar IPv4 dotted decimal. When values move between router output, tickets, DNS work, spreadsheets, and firewall rules, a harmless spelling change can look like a different address.

Normalization gives the address one reliable shape before you compare it. Expanding the address exposes all eight 16-bit hextets, while compression gives a short form that is easier to paste into notes and configuration review. The important check is not only whether the text is legal, but whether the prefix, zone identifier, embedded IPv4 bytes, and reverse DNS name still match the record you meant to inspect.

Prefix notation such as /64 describes how many leftmost bits belong to the network prefix. A zone identifier such as %en0 is local context for scoped addresses, most often link-local addresses on a host with more than one interface. Neither suffix changes the 128-bit address value, but dropping either one can make copied documentation misleading.

Formatting cannot prove that an address is assigned, reachable, routable, or safe to use in production. It can remove ambiguity from the text you were given, expose the hextets that matter for a review, and give you a reverse DNS name without manual nibble reversal.

Technical Details:

An IPv6 text form must resolve to eight 16-bit hexadecimal groups. RFC 4291 allows omitted leading zeros within a group, one :: shorthand for one or more all-zero groups, CIDR-style prefix lengths, and mixed IPv6 plus IPv4 notation for the low-order 32 bits. RFC 5952 narrows those choices for canonical text by preferring lowercase hexadecimal, suppressing leading zeros, and shortening the longest zero run once when that run is at least two hextets long.

The parser first works on the first nonblank line. It separates a valid prefix suffix from /0 through /128, keeps a zone identifier that follows %, and turns a dotted IPv4 tail into the final two hextets when all four octets are from 0 to 255. The remaining address must then expand into exactly eight legal hextets. Invalid attached details can produce warnings while the base address still normalizes.

The expansion rule can be summarized as eight hextets of 16 bits each.

The reverse DNS name uses the expanded 32 hexadecimal nibbles, reversed one nibble at a time, followed by ip6.arpa.

The Address Details result also splits the expanded address at a fixed /64 point into a network half and an interface half. That view is useful because many IPv6 subnets use 64-bit interface identifiers, but it is not a routing inference. A typed prefix such as /48, /56, or /127 remains its own field.

The dotted-tail display is another presentation choice. It can show the final 32 bits as four decimal IPv4 octets, while the expanded and compressed canonical values still come from the same 128-bit address.

Everyday Use & Decision Guide:

Paste the address exactly as you received it when you are trying to audit another source. Keeping the prefix and zone text intact lets the result show whether those suffixes were present in the original record. If the value came from a command that used a link-local address, the zone identifier is often the detail that decides which local interface the command meant.

Use the compressed result for clean runbook text, ticket comments, and configuration snippets where the short spelling is easier to read. Use the expanded result for careful comparison, reverse DNS preparation, and reviews where the position of each hextet matters. If two pasted values appear different, expand both before deciding they point to different 128-bit addresses.

Hextet Breakdown is best for finding exactly which group changed. Binary Blocks is more useful when a prefix boundary, byte boundary, or nibble boundary is the part under review. The JSON result is a compact audit record of the input, parsed suffixes, warnings, canonical forms, address type, and display settings.

• Keep lowercase output for standards-oriented documentation and comparisons.
• Use uppercase display only when matching an older document or team convention.
• Turn on dotted-tail display when the final 32 bits should remain recognizable as IPv4.
• Treat the type badge as a quick range hint, then verify routing, assignment, and DNS separately.
• Do not use the fixed /64 split as proof that the real network prefix is /64.

Step-by-Step Guide:

1. Enter one IPv6 address or IPv6/CIDR value in the address field.
2. Leave a valid prefix attached when the source value includes one, such as 2001:db8::42/64.
3. For scoped addresses, place the zone identifier before the prefix, for example fe80::1%en0/64.
4. Open Advanced if you need uppercase display, dotted IPv4 tail rendering, or binary groups of 1, 4, 8, or 16 bits.
5. Read the compressed and expanded outputs first, then use Address Details, Hextet Breakdown, Binary Blocks, or JSON for the evidence you need.
6. If validation fails, check for a second ::, a hextet longer than four hex digits, an IPv4 octet outside 0 to 255, or a prefix outside /0 to /128.

Interpreting Results:

A valid result means the text could be turned into one legal 128-bit IPv6 value after the optional prefix, zone identifier, and dotted tail were handled. It does not mean the address is assigned to a host, visible in DNS, permitted by a firewall, or reachable from your network.

False confidence usually comes from copying only the pretty address. Keep the prefix badge, zone badge, warnings, and address type visible while you compare the normalized result against the source system.

Common Mistakes:

Worked Examples:

FAQ:

Glossary:

Hextet

One 16-bit IPv6 group written as one to four hexadecimal digits.

Prefix length

The number after / that says how many leftmost bits belong to the network prefix.

Zone identifier

Local scope text after %, such as an interface name or numeric zone index.

Dotted IPv4 tail

The final 32 bits of an IPv6 address shown as four decimal IPv4 octets.

Reverse name

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

References:

• RFC 4291, IPv6 Addressing Architecture, IETF RFC Editor, February 2006.
• RFC 5952, A Recommendation for IPv6 Address Text Representation, IETF RFC Editor, August 2010.
• RFC 4007, IPv6 Scoped Address Architecture, IETF RFC Editor, March 2005.
• RFC 3596, DNS Extensions to Support IP Version 6, IETF RFC Editor, October 2003.
• IANA IPv6 Special-Purpose Address Space, IANA.