Skip to tool
ecech.
Finance English Developer Text & SEO Network Time E-commerce Math Design Health YouTube Image Converters Home
🌐 Network & IP

IPv6 Compressor That Produces the RFC 5952 Canonical Form, Not Just a Valid One

The same address has many valid spellings and exactly one canonical one. If your code compares addresses as strings, only the canonical form is safe.

Canonical — RFC 5952

—

Fully expanded

—

What changed, and which rule

The eight groups

Other representations

Advertisement

How the calculation works

Two runs of zeros. Only one of them may be replaced. 2001:db8:0:0:1:0:0:0 Valid, but not canonical 2001:db8::1:0:0:0 Replaced the first run, which is 2 groups long. Shorter string than it needs to be, and a different string from what other tools emit. Canonical 2001:db8:0:0:1:: Replaced the longest run, which is 3 groups. Counter-intuitive: the canonical form here is the one that still contains literal zeros. Both parse to the same 128 bits. Only one survives a string comparison against another system. RFC 5952 exists so that two implementations independently produce the same text.

How to Use This Tool

Paste an address in any valid form. You get the fully expanded version and the RFC 5952 canonical version, plus a list of which rule caused each change.

Why “valid” is not enough

IPv6 lets you write the same 128 bits many ways. 2001:DB8:0:0:0:0:0:1, 2001:db8:0:0::1 and 2001:db8::1 are one address and three strings.

That is fine until something compares them as text — and text comparison is everywhere: allow-lists, grep over logs, a unique index on a varchar column, a cache key, a rate-limit bucket. Two systems that both shorten “correctly” but differently will disagree, and the failure looks like an intermittent access bug rather than a formatting one.

RFC 5952 fixes that by defining one canonical text form. Four rules do the work:

  1. Leading zeros are dropped. 0db8 becomes db8, 0000 becomes 0.
  2. Hex is lowercase. DB8 becomes db8.
  3. :: replaces the longest run of zero groups — and on a tie, the leftmost of them.
  4. :: is never used for a single zero group.

The two rules tools get wrong

Rule 3 produces results that look unfinished. 2001:db8:0:0:1:0:0:1 has a run of two zeros and then another run of two zeros — a tie, so the leftmost wins and the canonical form is 2001:db8::1:0:0:1. But in 2001:db8:0:0:1:0:0:0 the second run is longer, so the canonical form is 2001:db8:0:0:1::, which still has two visible zeros in it. That looks like a job half done, and it is correct.

Rule 4 is the one almost every online compressor violates. 2001:db8:0:1:1:1:1:1 has a single zero group. Replacing it gives 2001:db8::1:1:1:1:1, which is one character shorter and not canonical. The rule exists because :: standing for exactly one group carries no information and creates two spellings where one would do.

Choosing which run to replace 2001 db8 0 0 1 0 0 0 run of 2 — left alone run of 3 — replaced Canonical: 2001:db8:0:0:1:: The surviving 0:0 is required. Replacing it instead would be valid IPv6 and non-canonical text.
Longest run wins, even when the shorter run comes first and looks tidier.

What this does not do

Zone identifiers (%eth0) and prefix lengths (/64) are accepted and passed through unchanged, but not validated — a zone ID is a local interface name and there is nothing to check it against. Embedded IPv4 in the last 32 bits is recognised and reported, but the canonical output keeps the dotted form only for addresses where RFC 5952 says it belongs.

Advertisement

Frequently Asked Questions

What is the canonical form of an IPv6 address?
The single text representation defined by RFC 5952: leading zeros dropped, lowercase hex, and :: replacing the longest run of zero groups — the leftmost on a tie — but never a single zero group. It exists so that two independent implementations produce the same string for the same address.
Why does it matter if my address is valid but not canonical?
Because software compares addresses as text far more often than it should: allow-lists, log searches, unique indexes, cache keys, rate-limit buckets. Two systems that both shorten correctly but differently will disagree about whether they are looking at the same address, and it presents as an intermittent access bug rather than a formatting problem.
Why is 2001:db8::1:1:1:1:1 not canonical?
Because :: is standing in for exactly one zero group, and RFC 5952 forbids that. A double colon replacing a single group saves one character and carries no information, while creating a second spelling of an address that already had one. The canonical form is 2001:db8:0:1:1:1:1:1.
Which run of zeros gets replaced when there are two?
The longest one. If two runs are the same length, the leftmost. This produces results that look unfinished — an address whose second zero run is longer canonicalises to something that still contains visible zeros — but it is what the specification requires and what other compliant implementations will emit.
Does this handle /64 prefixes and zone IDs?
They are accepted and passed through unchanged. A prefix length is not part of the address, and a zone identifier like %eth0 names a local interface, so there is nothing meaningful to validate it against.
Is my address sent anywhere?
No. The parsing and formatting run entirely in your browser. Nothing is uploaded and nothing is stored.

Related tools in Network & IP

🌐Password GeneratorGenerated with your browser's cryptographic RNG, scored in bits of entropy rather than a vague coloured bar, with crack-time estimates for four attacker budgets. 🌐CIDR to Subnet MaskEvery prefix from /0 to /32 with its netmask, wildcard, host count and binary. Handles /31 and /32, which the usual formula gets wrong. 🌐IP Range to CIDR192.168.1.5 to 192.168.1.10 is four CIDR blocks, not one. Firewalls want CIDR and people think in ranges, so here is the exact conversion. 🌐Subnet CalculatorNetwork, broadcast, first and last usable address, mask, wildcard and host count — from any CIDR or dotted mask, with the binary boundary shown so it makes sense.
#ipv6 #network #addressing
Browse all Network & IP tools
The desk where ecech. tools get written: a laptop, a notebook of to-dos and a whiteboard listing the tools on the site.

Made by one person

ecech. is not a content farm. Every tool here is written and checked by hand, one at a time, by someone who wanted the tool to exist and could not find a version that showed its working.

No accounts and no sign-in, and nothing you type reaches a server — every calculation on this page runs inside your browser. The ads are served by Google and do set their own cookies, which is set out in full on the privacy page. More about the site.