BYTETOOLS

IPv6 Address Compressor

Shorten any IPv6 address to its canonical RFC 5952 form, see the fully expanded version beside it, and compress a whole list at once.

Compressed (RFC 5952 canonical)

2001:db8::ff00:42:8329

Fully expanded

2001:0db8:0000:0000:0000:ff00:0042:8329

3
Zero groups collapsed
none
Zone ID
No
Already canonical

Step by step

  1. 1. Lower-case every hex digit and pad to eight groups: 2001:0db8:0000:0000:0000:ff00:0042:8329
  2. 2. Strip the leading zeros from each group: 2001:db8:0:0:0:ff00:42:8329
  3. 3. Collapse the longest run of all-zero groups — 3 groups starting at group 3 — into "::".
  4. 4. Result: 2001:db8::ff00:42:8329

Detected as: Documentation prefix (2001:db8::/32)

What is the IPv6 Address Compressor?

The IPv6 Address Compressor rewrites an address into the single canonical short form defined by RFC 5952: lower-case hex, no leading zeros in any group, and the longest run of two or more all-zero groups replaced by a double colon.

  • Strict RFC 5952 canonical output including the leftmost-run tie-break rule
  • Expanded and compressed forms shown side by side
  • Step-by-step explanation of the zeros that were removed
  • Handles zone identifiers (%eth0) and IPv4-mapped addresses
  • Bulk mode compresses a list of addresses, flagging any invalid lines
  • Identifies the address type — link-local, ULA, multicast, documentation and more

How to use the IPv6 Address Compressor

  1. 1

    Paste an IPv6 address in any notation — long, short, upper case, with a zone ID or an IPv4 tail.

  2. 2

    Read the canonical compressed form and copy it with one click.

  3. 3

    Compare it with the fully expanded form and follow the step-by-step explanation of what was removed.

  4. 4

    Toggle the dotted-quad option if you prefer ::ffff:c0a8:1 over ::ffff:192.168.0.1.

  5. 5

    Paste a whole list into the bulk box to compress many addresses at once.

About the IPv6 Address Compressor

The IPv6 Address Compressor rewrites an address into the single canonical short form defined by RFC 5952: lower-case hex, no leading zeros in any group, and the longest run of two or more all-zero groups replaced by a double colon. When two zero runs are the same length the leftmost one wins, and a single zero group is never compressed — the two rules people most often get wrong by hand.

It shows the fully expanded eight-group form next to the compressed one and walks through each step, so it doubles as a teaching aid. Zone identifiers such as %eth0 are preserved, and IPv4-mapped addresses can be written with a dotted-quad tail exactly as RFC 5952 recommends.

There is also a bulk box for compressing a whole list of addresses in one go — useful for tidying a firewall rule set or a DNS zone. All parsing runs 100% locally in your browser and no address is ever uploaded.

Frequently asked questions

How do you shorten an IPv6 address?

Drop the leading zeros in each of the eight groups, then replace the longest run of consecutive all-zero groups with a double colon. So 2001:0db8:0000:0000:0000:ff00:0042:8329 becomes 2001:db8::ff00:42:8329. You may only use one double colon per address.

Can you use :: twice in an IPv6 address?

No. A second double colon would make the address ambiguous, because there would be no way to tell how many zero groups belong to each one. Addresses with two are rejected as invalid, which is exactly what this tool does.

Should a single zero group be written as ::?

No. RFC 5952 section 4.2.2 forbids it, so 2001:db8:0:1:1:1:1:1 stays as it is rather than becoming 2001:db8::1:1:1:1:1. Compressing a single group saves nothing and creates two valid spellings of the same address.

Which zero run gets compressed when two are the same length?

The leftmost one. In 2001:db8:0:0:1:0:0:1 both runs are two groups long, so the canonical form is 2001:db8::1:0:0:1. Picking the wrong run is the most common reason two tools disagree about an address.

Why does canonical form matter?

Because logs, access control lists and databases compare addresses as strings. If one system writes 2001:DB8::1 and another writes 2001:0db8:0000:0000:0000:0000:0000:0001, a naive comparison says they are different hosts. Normalising to RFC 5952 form before storing avoids that whole class of bug.

Related tools