IPv6 Without Crying (The Accordion Method)
The compression method that finally makes sense — fold the zeros shut like an accordion, no guessing which parts disappear.
Why an IPv6 address looks like a keyboard accident
Thirty-two hex digits, split into eight groups of four, separated by colons that all start to look the same after the third group. Somewhere in the middle there's usually a stretch of nothing but zeros, and by the time you reach the end you've forgotten what the beginning said. That's not you being bad at this — that address genuinely has more characters in it than most people's Wi-Fi passwords.
Here's the part that actually helps: almost nobody writes an IPv6 address out in full. There's a compression rule built directly into the standard, and once you see it as three small, repeatable moves instead of one intimidating wall of hex, it stops being a wall.
The Accordion Method, in one paragraph
An IPv6 address is eight hextets — eight groups of up to four hex digits — lined up in a row like an accordion's pleats. Most of those pleats are just padding: leading zeros that don't change the value, the same way 007 and 7 mean the same number. You flatten those first. Then, if there's a run of hextets that are entirely zero — not just short, actually zero — you fold that whole run shut in one motion and mark the fold with a double colon (::). Everything that wasn't zero never moves and never gets touched.
Step 1: See the whole thing expanded first
Before compressing anything, know what you're starting with: eight hextets, colon-separated, each one 16 bits. If a real device hands you a compressed address, expand it back out first so you're not compressing blind — pad every shortened hextet back to four digits, and insert enough all-zero hextets at the :: to make eight total.
Example, fully expanded: 2001:0db8:0000:0000:0000:0000:1234:5678. Eight groups. Nothing hidden. This is the address's true, literal form.
Step 2: Drop the leading zeros, hextet by hextet
Inside each hextet on its own, strip any zeros sitting in front of the first nonzero digit. 0db8 becomes db8. 0000 becomes 0 (a single zero — you still can't leave a hextet completely blank yet, that comes next). 1234 and 5678 already have no leading zeros, so they don't change at all.
After this pass: 2001:db8:0:0:0:0:1234:5678. Shorter, but still eight groups — this step never removes a whole hextet, only its padding.
Step 3: Fold the one longest all-zero run shut
Now look for the single longest unbroken run of hextets that are entirely zero. Fold that whole run into ::, and delete the individual zeros it replaced. In the example, the four zero hextets in the middle collapse into one ::.
Result: 2001:db8::1234:5678. Same address. Way less typing.
Two rules that trip people up if you skip them: :: can only appear once in an address (if it appeared twice, nobody could tell how many zero-hextets belong to each ::), and if there are two separate zero-runs of different lengths, only the longest one folds — a shorter run stays written out in full, zeros and all.
The whole method, one more time, fast
1) Start from the fully expanded, eight-hextet form.
2) Inside each hextet, drop leading zeros (007 → 7).
3) Find the single longest run of all-zero hextets and fold it into :: — only once, only the longest run.
That's the entire skill. Expanding is just this in reverse: count the hextets you can see, figure out how many zero-hextets the :: is standing in for, and pad each remaining hextet back to four digits.
Worked example, start to finish
Question: Compress fe80:0000:0000:0000:0000:0202:b3ff:fe1e.
Drop leading zeros inside each hextet: fe80:0:0:0:0:202:b3ff:fe1e.
Find the longest all-zero run: four hextets in a row, right after fe80.
Fold that run into ::, leaving everything else untouched: fe80::202:b3ff:fe1e.
Reverse check: fe80, then ::, then 202:b3ff:fe1e is three hextets — so the :: must be standing in for 8 − 1 − 3 = 4 zero hextets. That matches what we folded. The compression is reversible, which is exactly how you'd verify an answer under exam pressure.
Mistakes that will happen to you (and how to catch them)
Using :: twice in one address. It's tempting when there are two separate zero-runs, but :: can only ever appear once — if both runs are the same length, fold the first (leftmost) one and leave the other written out.
Folding a run that isn't actually the longest. A three-hextet zero-run loses to a four-hextet zero-run even if the shorter one comes first — always scan the whole address before folding, don't fold the first zero-run you spot.
Dropping a trailing significant zero by accident. Leading zeros inside a hextet disappear (0db8 → db8), but a zero that isn't leading stays — 2001:0db0 compresses to 2001:db0, not 2001:db. Only zeros in front of the first nonzero digit are padding.
Forgetting IPv6 has no broadcast address at all. There's nothing to fold there because there's nothing to compress — multicast and Neighbor Discovery cover what broadcast used to do in IPv4, a completely different mechanism, not just a renamed one.
When you're ready for speed
This guide teaches the fold so it actually makes sense. Once it clicks, the ITCertFoundry IPv6 Compression & Scope Tricks guide covers the same rules condensed into exam-speed shortcuts, plus the address-type and scope table worth memorizing alongside it.
Want a printable copy?
This complete guide is also available as a professionally formatted PDF.
Download PDF ↓