IPv6 Address Compressor / Expander

Introduction:

IPv6 addresses are easy to misread because the same 128-bit value can be written in several legal text forms. Leading zeros may appear or disappear, one run of zero hextets may collapse into ::, and some addresses may show the last 32 bits as an IPv4 dotted tail. This tool checks one pasted address, tells you whether the text is valid, and then shows both a short form and a fully expanded form so you can compare them without doing the rewrite by hand.

It accepts plain IPv6 text, an optional prefix length such as /64, a zone identifier such as %eth0, and mixed notation such as ::ffff:192.0.2.1. When the address parses cleanly, the result panel also labels the address type, breaks the value into eight hextets, shows the 128-bit binary string, and builds the reverse ip6.arpa name used for DNS pointer work.

That makes the tool useful for documentation cleanup, ACL review, DNS troubleshooting, and side-by-side comparison of values copied from routers, logs, spreadsheets, or tickets. The export options also help when you need a quick CSV, JSON, or DOCX snapshot of what the parser saw.

The result is a formatting and interpretation aid, not a live network test. A value can be valid here and still be unreachable, assigned to the wrong host, or paired with the wrong prefix in a real deployment.

Technical Details:

IPv6 uses eight 16-bit groups written in hexadecimal. RFC 4291 allows more than one text representation for the same address, while RFC 5952 recommends a canonical style so operators can compare records without guessing whether a different spelling is actually a different endpoint. The tool follows that general workflow by first normalizing the address to eight four-digit groups, then deriving a compressed view, a binary view, and the reverse DNS pointer from the normalized value.

The parser handles optional suffixes before validation is finished. If you add a prefix length, it checks that the number is from 0 to 128. If you add a zone identifier after a percent sign, it keeps that zone text separate from the address itself. If the last portion looks like dotted IPv4, the tool converts those four bytes into the final two hextets before continuing. Only after those steps does it decide whether the address can expand into exactly eight valid groups.

If you need RFC 5952-style text for documentation, keep the hex case option on lower. The tool can also show uppercase output for display preference, but that does not change the underlying 128-bit value. The dotted-tail toggle is also a presentation choice. It rewrites only the last 32 bits of the displayed address when that view is useful, especially for IPv4-mapped addresses.

The Address Details tab also shows a /64 network half and a /64 interface half. That split is helpful because many operational IPv6 subnets still use /64, but it is only a fixed inspection lens here. It does not mean the tool detected a real routing boundary from your input. A typed prefix such as /48 or /127 is preserved separately as its own field.

All parsing, formatting, copying, and file generation happen in the browser. There is no server-side helper for this tool. Non-default inputs can still appear in the page query string, so do not share a bookmarked or copied page link if the address should stay private.

Everyday Use & Decision Guide:

Start by pasting the address exactly as you received it. If the text already includes a prefix length, leave it in place so the prefix badge reflects what the source actually showed. If the address is link-local and came from a local command such as a ping, traceroute, or SSH example, keep the zone identifier too. That is often the missing detail when a copied address looks valid but still fails in practice on a multi-interface host.

Use the compressed view when you want cleaner text for documentation or ticket comments. Use the expanded view when exact group boundaries matter, especially for reverse DNS, firewall review, and manual comparison against logs or spreadsheets. If you are dealing with IPv4-mapped addresses, the dotted-tail option is a readability choice for mixed environments, not a different address family.

Open the Hextet Breakdown tab when the real question is, "Which group changed?" Open Binary Blocks when the real question is, "Where is the prefix boundary?" Those views stop you from mentally expanding and regrouping the address every time you compare two similar-looking values. For saved evidence, the CSV, JSON, and DOCX exports capture the same parsed result you see on screen.

• Keep hex case on lower when you want RFC 5952-style documentation output.
• Use uppercase only when a team style guide or legacy document format requires it.
• Keep dotted-tail display for IPv4-mapped or mixed-stack troubleshooting, not for generic IPv6 notation cleanup.
• Treat the type badge as a range hint, not as proof of reachability or current routing policy.

Step-by-Step Guide:

1. Paste one IPv6 address into the input field.
2. If the source includes a prefix length, leave it attached as /n.
3. If the address is non-global and needs interface context, add the zone identifier before the prefix length, such as fe80::1%en0/64.
4. If the last 32 bits are meant to be shown as IPv4, enter them after the final colon as a dotted quad.
5. Open Advanced only if you want uppercase display, dotted-tail rendering, or a different binary grouping size.
6. Read the Address Details tab first, then switch to Hextet Breakdown, Binary Blocks, or JSON depending on what you need to inspect or export.

Interpreting Results:

A green Valid badge means the address could be normalized after optional suffix handling. It does not mean the prefix is deployed correctly or that the host exists. A red Invalid badge means the parser could not build a legal eight-group address from the text.

• Warnings can appear even when the address itself is valid. For example, an out-of-range prefix is dropped with a warning while the base address may still parse correctly.
• Prefix badge echoes the suffix you entered. It is useful context, but it does not change the fixed /64 split shown in the details table.
• Zone badge reminds you that the address was entered with local scope context. That suffix is about interface or zone selection, not part of the raw 128-bit address.
• Type label comes from the checked prefix pattern. If the badge says Documentation or IPv4-mapped, that is often the fastest clue that the text is not ordinary production unicast space.
• Reverse name is already arranged in nibble-reversed order for DNS. You should not reverse it again before using it in PTR work.

If you are comparing two addresses and only one seems to match, switch both to expanded form first. Many apparent differences disappear once every hextet is padded to four digits and every compressed zero run is made explicit.

Worked Examples:

FAQ:

Glossary:

Hextet

One 16-bit IPv6 group written in hexadecimal.

Prefix length

The number of leading bits that identify the network portion of an address.

Zone identifier

Local scope context appended after %, usually for non-global addresses such as link-local values.

IPv4-mapped address

An IPv6 format that carries an IPv4 address in the last 32 bits, usually under ::ffff:0:0/96.

Reverse pointer

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

References:

• RFC 4291, IPv6 Addressing Architecture
• RFC 5952, A Recommendation for IPv6 Address Text Representation
• RFC 4007, IPv6 Scoped Address Architecture
• RFC 3596, DNS Extensions to Support IP Version 6
• IANA IPv6 Special-Purpose Address Space