IPv6 Compressor
Compress an expanded (long-form) IPv6 address to the shortest canonical form defined by RFC 5952: leading zeros stripped, lowercase hex, and the longest run of zero groups replaced with a single ::. See exactly what happens to every segment, validate addresses, or compress a whole list at once.
Compressed (RFC 5952 canonical form)
| Segment | Original | Leading zeros stripped | Role in output |
|---|
| # | Input | Compressed (RFC 5952) | Status |
|---|
The 5 RFC 5952 compression rules
- Write every hex digit in lowercase (§4.3).
- Strip leading zeros in each group: 0db8 → db8, 0042 → 42 (§4.1).
- Replace the longest run of consecutive all-zero groups with one :: (§4.2.3).
- Never use :: for a single zero group (§4.2.2).
- If two zero runs tie in length, compress the leftmost one. :: may appear only once (§4.2.3).
Worked examples
Each pair below was recomputed by hand from RFC 5952 and cross-checked against the engine. Paste any input into the compressor to see its per-segment steps.
| Input (expanded) | Compressed | Why |
|---|---|---|
| 2001:0db8:0000:0000:0000:ff00:0042:8329 | 2001:db8::ff00:42:8329 | Longest zero run (3 groups) → :: |
| 2001:0db8:0000:0000:0008:0800:200c:417a | 2001:db8::8:800:200c:417a | RFC 5952 §5 unicast example |
| ff01:0000:0000:0000:0000:0000:0000:0101 | ff01::101 | RFC 5952 §5 multicast example |
| 0000:0000:0000:0000:0000:0000:0000:0001 | ::1 | Loopback |
| 0000:0000:0000:0000:0000:0000:0000:0000 | :: | Unspecified address |
| 2001:0db8:0000:0000:0001:0000:0000:0001 | 2001:db8::1:0:0:1 | Tie (2 vs 2) → leftmost run wins |
| 2001:0db8:0000:0001:0001:0001:0001:0001 | 2001:db8:0:1:1:1:1:1 | Single zero group stays written out (§4.2.2) |
| 2001:0DB8:85A3:08D3:1319:8A2E:0370:7334 | 2001:db8:85a3:8d3:1319:8a2e:370:7334 | No zero run — lowercase + strip zeros only |
| fe80:0000:0000:0000:0202:b3ff:fe1e:8329 | fe80::202:b3ff:fe1e:8329 | Link-local: 3-group run → :: |
| 2001:0db8:abcd:0000:0000:0000:0000:0000 | 2001:db8:abcd:: | Trailing zero run |
| 2001:0000:0000:0001:0000:0000:0000:0003 | 2001:0:0:1::3 | Longer run (3) beats shorter run (2) |
| 64:ff9b:0000:0000:0000:0000:c000:0201 | 64:ff9b::c000:201 | NAT64 prefix address |
Related tools (different jobs)
- IPv4 to IPv6 Converter — the opposite axis: maps an IPv4 address into IPv6 transition encodings (mapped, 6to4, Teredo, ISATAP, NAT64). This page shortens addresses that are already IPv6.
This page is the dedicated IPv6 compressor: expanded/long form in, shortest RFC 5952 form out. Expansion (short form back to full) is the reverse operation.
Frequently asked questions
What does RFC 5952 say about compressing IPv6 addresses?
RFC 5952 defines the single canonical short form of an IPv6 address: hex digits in lowercase (section 4.3), leading zeros stripped in every group (section 4.1 — so 0db8 becomes db8), and the longest run of consecutive all-zero groups replaced with "::" (section 4.2.3). The "::" may appear only once, and it must never be used to shorten a single 16-bit 0 field (section 4.2.2). If two zero runs tie in length, the first (leftmost) run is compressed. The compressor above implements all of these rules.
When is it legal to use "::" in an IPv6 address?
Only to replace the longest run of two or more consecutive all-zero groups — for example 2001:0db8:0000:0000:0000:0000:0002:0001 becomes 2001:db8::2:1. The double colon may appear only once per address (2001:db8::1::2 is invalid), and a lone zero group is always written out: 2001:db8:0:1:1:1:1:1 is correct, not 2001:db8::1:1:1:1:1. When two zero runs tie in length, the leftmost run wins — 2001:0db8:0000:0000:0001:0000:0000:0001 compresses to 2001:db8::1:0:0:1.
Does compression lose information? Can I get the original form back?
No information is lost — "::" is pure shorthand. To expand an address again, replace "::" with as many all-zero groups as needed to reach eight groups total, then pad every group back to four digits. That expansion step is the reverse direction and belongs to a different tool; this page is the dedicated compressor (expanded/long form in, shortest RFC 5952 form out).
How is this different from the IPv4 to IPv6 converter?
They solve different problems. The IPv4 to IPv6 converter (/tools/ipv4-to-ipv6/) maps an IPv4 address into IPv6 transition encodings: IPv4-mapped (::ffff:a.b.c.d), 6to4, Teredo, ISATAP, and NAT64. This page takes an address that is already IPv6 — usually written in long expanded form — and shortens its text representation according to RFC 5952. Shortening an IPv6 address and translating IPv4 into IPv6 are two separate jobs.
Why do two text forms of the same address compare as different strings?
Because string comparison does not know they are the same address: 2001:0DB8:0000:0000:0000:ff00:0042:8329 and 2001:db8::ff00:42:8329 are the identical address, but firewall rules, ACL diffs, allowlists, and log searches treat them as different text. Compressing everything to the single RFC 5952 canonical form makes textual comparison reliable — which is why DNS zone files, configs, and security tooling normalize addresses to it.
Is my input sent to a server?
No. Compression runs entirely in JavaScript inside your browser — no address you type is transmitted anywhere. You can disconnect from the network after the page loads and the tool keeps working.
What counts as a valid IPv6 address here?
Either the full form — eight groups of 1 to 4 hexadecimal digits, for example 2001:0db8:0000:0000:0000:ff00:0042:8329 — or an already-shortened form with exactly one "::", for example 2001:db8::1 (the tool re-canonicalizes it per RFC 5952). Square brackets from URI literals and zone IDs such as fe80::1%eth0 are tolerated and ignored. Anything else — wrong group counts, a second "::", non-hex characters — is rejected with a specific error message.
Can I compress many addresses at once?
Yes — switch to the Batch tab and paste one address per line. You get a table of inputs, compressed outputs, and per-line status, plus copy-all and CSV/TXT download. Thousands of lines are fine, and everything still runs locally in your browser.
Free tool by NRTechStudio