search

Found

info Overview

Enter an IPv6 address to see its RFC 5952 compressed form, full expansion, uppercase variant, and IPv4-mapped dotted form, plus zero-run and length stats.

📘 How to Use

  1. Paste an IPv6 address into the input field
  2. Compare the RFC 5952 compressed, fully expanded, uppercase, and IPv4-mapped forms
  3. Check the address details card for zero-run count and character length

IPv6 Address Zero Compression Formatter

Eight colon-separated hex groups. Shorthand with ::, embedded IPv4 tail, and %zoneid are all accepted.

RFC 5952 compressed

RFC 5952
—

Replaces the longest run of two or more zero hextets with :: and strips leading zeros per RFC 5952.

Fully expanded

expanded
—

All eight hextets shown with four hex digits each, useful for log matching and PTR records.

Uppercase compressed

uppercase
—

Same compressed layout but with uppercase hex digits, for comparing with older device output.

IPv4-mapped form

IPv4-mapped
—

Shown only for addresses in ::ffff:0:0/96; outside that range, the field reads N/A.

Address details

Compressed characters
—
Expanded characters
—
Zero runs
—
Longest zero run
—

※ RFC 5952: when two or more zero runs exist, the longest is collapsed to ::; ties resolve to the leftmost run.

※ IPv4-mapped notation is generated only for ::ffff:0:0/96 addresses (first 80 bits zero, next 16 bits ffff).

Copied!

grid_view Related

Article

IPv6 Address Zero Compression Formatter | Canonicalize IPv6 to RFC 5952

Enter one IPv6 address and get four forms side by side: the RFC 5952 compressed canonical form, the fully expanded eight-hextet form, an uppercase compressed variant, and the IPv4-mapped dotted form. Zero-run count, longest run, and character lengths are shown so you can see exactly why two strings disagree.

💡 About this tool

The painful thing about IPv6 is that one address has many legal spellings. 2001:db8::1 and 2001:0db8:0000:0000:0000:0000:0000:0001 are the same address but completely different strings. When you diff a firewall ACL against a router config, or grep a PTR record against an access log, a mismatch in spelling reads as a mismatch in value — even though the bits are identical.

RFC 5952 fixes this by defining one canonical text representation: collapse the single longest run of two or more zero hextets to ::, strip leading zeros from each group, and use lowercase hex. This tool applies those rules mechanically and shows the canonical form next to the fully expanded form (handy for log matching and PTR records) and an uppercase variant for comparing against older gear that still prints uppercase. For addresses inside ::ffff:0:0/96 it also produces the ::ffff:a.b.c.d dotted form; outside that range the field reads N/A. It is built for anyone trying to make IPv6 spelling agree across devices, logs, and docs.

🧐 Frequently Asked Questions

Q. Where exactly does :: go? A. RFC 5952 collapses the single longest run of two or more consecutive zero hextets. When two runs tie in length, the leftmost one wins. A run of a single zero is never shortened to ::.

Q. What happens with an address that has two separate zero runs? A. Only the longer run collapses. For example 2001:0:0:1:0:0:0:1 compresses the trailing three-zero run into 2001:0:0:1::1. The details card shows the run count and longest run so you can confirm which one was chosen.

Q. Why does the IPv4-mapped field say N/A? A. The ::ffff:a.b.c.d notation only exists for addresses in ::ffff:0:0/96 — the first 80 bits zero, the next 16 bits ffff. Any other address has no IPv4 spelling, so the field reads N/A.

Q. Are leading zeros removed? A. Yes. Each group drops its leading zeros: 0db8 becomes db8, 0042 becomes 42. The expanded form does the opposite, padding every group back to four digits.

Q. Can I include a zone ID like %eth0? A. Yes. The zone ID is excluded from the compression math and re-appended to the end of each output exactly as you typed it.

Q. Is the output guaranteed to be a single canonical string? A. For a valid address, yes — RFC 5952 was written so that every IPv6 address has exactly one recommended representation, which is the compressed form shown here.

📚 Why a second RFC was needed

RFC 4291 already allowed :: (used once) and the omission of leading zeros, but it described what was permitted, not what was canonical. That left 2001:db8:0:0:0:0:0:1 and 2001:db8::1 both valid, so different stacks and people emitted different strings for the same address.

That ambiguity made log correlation and address comparison error-prone, so RFC 5952 nailed down one recommended representation: lowercase hex, the longest zero run compressed, and leftmost-wins tie-breaking. IPv4 never had this problem — 192.0.2.1 looks the same no matter who writes it — but IPv6, with its longer addresses and optional shorthand, scatters into variants unless you normalize. That normalization is exactly the one step this formatter handles.