Paste a compressed IPv6 address and get the full 128-bit form — all eight hextets, in hex, decimal and binary. The result also names what kind of address it is, so fe80::1 comes back labelled link-local rather than just written out longer, and the canonical short form is there beside it for comparison.
Quick Answer: what does expanding an IPv6 address do?
Expanding writes an IPv6 address out in full — all eight hextets, four hex digits each, nothing left out. 2001:db8::1 becomes 2001:0DB8:0000:0000:0000:0000:0000:0001, and an expanded address is always exactly 39 characters. The address itself does not change: the same 128 bits are simply written without the two shortcuts IPv6 allows, dropped leading zeros and the ::.
Enter any IPv6 address — compressed or already expanded. You get the full form, every hextet, and the address type.
Robert Harrison
OSINT & Network Utility Expert
Robert works on network diagnostics and the practical end of IP tooling — the conversions, lookups and calculations that sit underneath everything else.
This page used to expand and stop. That was only ever half the job: the same address written the other way is what your firewall, your logs and your operating system will print back at you, and if the two do not match as strings, a comparison quietly fails. So it now shows both, and names which one is canonical.
View all articles by RobertWhen you need to expand IPv6 address from its compressed form, you are converting a shortened notation back to the IPv6 full form. Our free IPv6 expander tool makes this process instant and accurate. Simply enter any compressed address, and the tool will uncompress IPv6 to show all 8 hextets with their complete leading zeros.
IPv6 addresses are 128-bit numbers, much longer than the 32-bit IPv4 addresses. To make these addresses readable, the internet community created compression rules. However, when you need to store addresses in databases, configure firewall rules, or perform network debugging, you must convert IPv6 to full notation first.
If the notation itself is new to you, what an IP address actually is covers the ground this page sits on, and the beginner's guide to IPv6 addresses explains the eight hextets and the :: shorthand from scratch.
There are several critical reasons to use an IPv6 full address converter:
Example: The compressed address 2001:db8::1 expands to 2001:0DB8:0000:0000:0000:0000:0000:0001. When you decompress IPv6, you restore all 5 hidden zero hextets and add leading zeros to each visible group.
Understanding how to expand IPv6 address manually helps you verify tool results and troubleshoot network issues. Here is the complete process to convert compressed IPv6 to full form:
The double colon (::) is the key to IPv6 expansion. This symbol represents one or more consecutive groups of zeros. When you expand IPv6 address with ::, you replace this shortcut with the actual zero hextets.
Important rule: The :: can only appear once in a valid IPv6 address. If you see it twice, the address is invalid because the system cannot determine how many zeros belong to each position.
A complete IPv6 address always has exactly 8 hextets (groups of 4 hex characters separated by colons). Count how many hextets you can see in the compressed address.
For example, in 2001:db8::8a2e:370:7334, you can see 5 hextets: 2001, db8, 8a2e, 370, and 7334. The IPv6 to full address conversion needs to account for the missing groups.
Subtract your count from 8 to find how many zero hextets the :: represents. In our example: 8 - 5 = 3 zero groups. This is the core of IPv6 double colon expansion.
Insert the calculated number of 0000 hextets where :: appears. Our example becomes: 2001:db8:0000:0000:0000:8a2e:370:7334.
Each hextet must have exactly 4 characters. Add leading zeros to any group with fewer than 4 digits. The final IPv6 full form is: 2001:0DB8:0000:0000:0000:8A2E:0370:7334.
Pro Tip: An expanded IPv6 address is always exactly 39 characters long (32 hex digits + 7 colons). Use this to verify your IPv6 expansion results. If your result is shorter or longer, something went wrong.
You will encounter several terms when working with IPv6 address conversion. Here is what each means:
IPv6 expand is the most common term for converting compressed addresses to full notation. When you expand IPv6, you restore all leading zeros and fill in the groups hidden by the :: shortcut. Our IPv6 expander tool uses this terminology.
Uncompress IPv6 means the same as expand. The term comes from the fact that compressed addresses use less space. When you uncompress IPv6 address online, you reverse the compression rules to show the complete address.
Unshorten IPv6 is another synonym. This term emphasizes that you are making a shortened address longer. Whether you say decompress IPv6, unshorten IPv6, or expand IPv6 address, the result is the same full 128-bit notation.
To normalize IPv6 means converting addresses to a standard format for consistent handling. Normalization usually includes expansion plus converting to lowercase or uppercase. When you normalize IPv6 addresses before storage, you ensure that comparisons work correctly regardless of how the original address was written.
Key Point: All these terms - ipv6 expand, ipv6 uncompress, ipv6 unshorten, decompress ipv6, and ipv6 normalize - describe the same fundamental process of converting shortened IPv6 to its full form.
Memorizing the IPv6 full form of frequently used addresses speeds up network troubleshooting. Here are important addresses every network professional should know:
Localhost (Loopback)
::1
IPv6 Full Form
0000:0000:0000:0000:0000:0000:0000:0001
When you expand IPv6 address ::1, seven zero hextets are revealed. This is the IPv6 equivalent of 127.0.0.1.
Unspecified Address
::
IPv6 Full Form
0000:0000:0000:0000:0000:0000:0000:0000
The IPv6 to full address conversion of :: shows all 128 bits as zeros. Used during initialization before receiving a proper address.
Google DNS (Primary)
2001:4860:4860::8888
IPv6 Full Form
2001:4860:4860:0000:0000:0000:0000:8888
Use this to test IPv6 connectivity. The decompress IPv6 result shows 4 hidden zero groups.
Cloudflare DNS
2606:4700:4700::1111
IPv6 Full Form
2606:4700:4700:0000:0000:0000:0000:1111
Privacy-focused DNS service. The unshorten IPv6 result reveals 4 zero hextets.
Link-Local Prefix
fe80::
IPv6 Full Form
FE80:0000:0000:0000:0000:0000:0000:0000
All link-local addresses start with fe80. When you convert IPv6 to full, 7 zero groups appear.
When you expand IPv6 address to its full form, you reveal the complete 128-bit structure that network devices process internally. Understanding this structure helps with network planning and security analysis.
The first half of an IPv6 address (64 bits, or 4 hextets) identifies the network. Your ISP assigns this network prefix to your organization. It includes the Global Routing Prefix (typically 48 bits) and Subnet ID (16 bits).
You can look up network prefix ownership using our WHOIS Lookup tool. This information is valuable for security investigations and understanding address allocation.
The second half (64 bits, or 4 hextets) is the interface identifier. This uniquely identifies a device on the network. It can be manually configured, assigned by DHCPv6, or auto-generated through SLAAC (Stateless Address Autoconfiguration).
IPv6 Structure (After IPv6 Expansion)
|-------- Network Prefix (64 bits) --------|--- Interface Identifier (64 bits) ---|
2001:0DB8:85A3:0000 : 8A2E:0370:7334:1234
Hextets 1-4: Network | Hextets 5-8: Device
Security Warning - SLAAC Privacy Leak: If you see FF:FE in the middle of the interface identifier after you uncompress IPv6, the device might be exposing its MAC address. For example, ::8A2E:03FF:FE70:7334 potentially contains leaked hardware information. Modern systems use randomized identifiers to prevent this. Check addresses in your network logs using our IPv6 expander to identify this vulnerability.
The need for an IPv6 expander exists because IPv6 addresses are fundamentally different from IPv4. Understanding these differences explains why we must compress and expand IPv6.
IPv4 uses 32 bits, providing about 4.3 billion unique addresses. This seemed enormous in the 1980s but is now exhausted. IPv6 uses 128 bits, providing 340 undecillion addresses (340 followed by 36 zeros). This abundance eliminates the need for NAT (Network Address Translation). Why IPv4 ran out and what it means is the longer version of that story.
IPv4 uses dotted decimal notation (like 192.168.1.1) which is easy to read. IPv6 uses colon hexadecimal notation. Without compression, the IPv6 full form is 39 characters long. Compression rules make addresses manageable, but you need tools to convert IPv6 to full form when precision matters.
Because IPv6 addresses are 4 times longer than IPv4, compression became necessary for human readability. But machines need the IPv6 full form, which is why tools to uncompress IPv6 address online are essential for network professionals. The two protocols differ in more than length — the IPv4 and IPv6 header comparison sets the packet formats side by side, field for field.
Expanding an address is usually half of a comparison. The other half is the short form, because that is what your operating system, your firewall and your logs actually print — and if the two spellings do not match character for character, a string comparison quietly fails even though both describe the same host. So the result above shows the short form too, labelled canonical.
Canonical is a stronger word than valid. 2001:0DB8::0001 is a perfectly valid address that every parser will accept. It is simply not the one spelling that RFC 5952 asks everyone to agree on, which is the point of having a canonical form at all: two systems that both follow it will always write one address the same way.
# 2001:0DB8:0000:0000:0000:0000:0000:0001
1. drop the leading zeros in each group → 2001:DB8:0:0:0:0:0:1
2. collapse the longest run of zero groups → 2001:DB8::1
3. lower case the hex letters → 2001:db8::1
This is worth stating precisely, because a lot of published guidance softens it. RFC 5952 uses MUST in all four places:
:: must take the longest run. Section 4.2.1 says it “MUST be used to its maximum capability”. In 2001:db8:0:0:0:1:0:1 there are two runs of zeros, of three and of one; the canonical form is 2001:db8::1:0:1, not 2001:db8:0:0:0:1::1.:: for a single zero group. Section 4.2.2: it “MUST NOT be used to shorten just one 16-bit 0 field”. So 2001:db8:0:1:1:1:1:1 stays exactly as written — shortening that one zero to 2001:db8::1:1:1:1:1 is wrong, even though it is shorter and still parses.a to f in lower case. 2001:DB8::1 and 2001:db8::1 are one address and two strings, which is the whole problem.When two runs are the same length, section 4.2.3 says the first one is shortened. 2001:db8:0:0:1:0:0:1 has two runs of two zeros, so the canonical form is 2001:db8::1:0:0:1 — the left-hand run collapses and the right-hand one is written out.
The short form on this page comes from inet_ntop(), the same system call your server uses to print an address, rather than from a hand-written routine. That is deliberate: it means the spelling you see here is the spelling your own machine would produce.
| Use the | When |
|---|---|
| Expanded form | Sorting or comparing addresses as text, storing them in a fixed-width column, or matching a prefix character by character. Every address is the same 39 characters, so nothing depends on how it happened to be written. |
| Canonical short form | Configuration files, documentation, anything a person reads — and any time you are comparing your input against what a log or a firewall printed, because that is the form they use. |
| Either | Typing an address into software. Parsers accept both; the difference is only in how it is written down. |
Shortening a whole list, or want to know which rule changed what? That is a different job from expanding one address, and the IPv6 compressor is built for it — bulk input, and a line for each RFC 5952 rule it applied. This page hands you the canonical form as a convenience; that one explains it.
If the address came out of a log or a packet capture and the next question is whose network it belongs to, the IP lookup answers that, and the subnet calculator works out what a given prefix length actually covers.
Two documents govern everything on this page. Knowing which one says what is useful when a tool, a vendor or a colleague tells you an address is written incorrectly.
RFC 4291 defines the structure. Section 2 opens with the sentence everything else rests on: “IPv6 addresses are 128-bit identifiers”. Section 2.2 gives the text form as “one to four hexadecimal digits of the eight 16-bit pieces” — eight groups of sixteen bits, which is where the eight hextets and the 39-character expansion both come from.
It also allows the two shortcuts. Leading zeros inside a group may be omitted, and one run of all-zero groups may be replaced by ::. Both are optional under RFC 4291, which is exactly why a second document was needed.
Published in 2010, RFC 5952 takes the freedom RFC 4291 allows and narrows it to a single recommended spelling. It does not add or remove any valid address; it decides which of the several legal ways to write one is canonical. The four rules above are its sections 4.1 to 4.3.
Uppercase in an expanded address is not an RFC 5952 violation. Section 4.3 governs the canonical short form. The expanded form is a display convenience rather than a form the RFC specifies, and uppercase hex is common in it precisely because it is easier to read in a column. The tool prints the expansion in uppercase and the canonical form in lower case, which is the convention most reference material follows.
It means writing the address out in full: all eight hextets, four hexadecimal digits in each, with nothing left out. 2001:db8::1 expanded is 2001:0DB8:0000:0000:0000:0000:0000:0001. Nothing changes about the address itself — the same 128 bits are simply written without the two shortcuts IPv6 allows, dropped leading zeros and the ::.
Count the hextets you can see, subtract that from eight, and replace the :: with that many 0000 groups. Then pad every remaining group to four digits with leading zeros. In 2001:db8::8a2e:370:7334 there are five visible hextets, so the :: stands for three zero groups. The result should always be exactly 39 characters — if it is not, a step went wrong.
Because the shortened form is what your operating system, your firewall and your logs will print back at you, and comparing the two is the commonest reason for expanding an address in the first place. The field is labelled RFC 5952 canonical and comes from the system call inet_ntop(), so it is the same spelling your server would produce. If shortening is the job rather than a side note — bulk input, rule-by-rule explanations of what changed — the IPv6 compressor linked further down this page is the tool built for it.
0000:0000:0000:0000:0000:0000:0000:0001. The :: stands for seven consecutive zero hextets. This is the loopback address, the IPv6 equivalent of 127.0.0.1, and the tool labels it as such in the result.
It is a valid address and every parser will accept it, but it is not the canonical form. RFC 5952 section 4.3 says the characters a to f in an IPv6 address must be written in lower case. That matters the moment addresses are compared as text — in an allowlist, a log filter or a database key, 2001:DB8::1 and 2001:db8::1 are two different strings for one address.
Exactly 39: thirty-two hexadecimal digits plus seven colons. That fixed width is the reason to store the expanded form — a fixed-width column sorts and compares character by character without any further work.
Because the expansion on its own often does not answer the question people arrived with. Someone pasting fe80::1 usually wants to know why that address will not route; the answer is that it is link-local. ::ffff:192.168.1.1 is the sharper case — expanded to 0000:...:FFFF:C0A8:0101 it stops looking like the IPv4 address it actually is. The type is read from the address bytes, so there is no lookup and nothing to go out of date.
Yes. Add ?ip= and the address — for example /ipv6-expansion?ip=2001:db8::1 — and the page loads with the result already on screen. The canonical URL stays /ipv6-expansion, so a shared link never competes with the page itself in search.
Yes, and it is worth being straight about it: this converter runs on the server, not in your browser, so the address you submit is sent to TrustMyIP, converted, and returned. This page writes nothing to a database. If an address is genuinely sensitive, the documentation range 2001:db8::/32 exists precisely so that examples can be shared without exposing a real one — and the tool will tell you when you are using it.
No. All four describe the same operation: turning a shortened IPv6 address back into its full 128-bit notation. Different vendors and manuals settled on different words. Normalise is the one that sometimes means something slightly wider, since it can include forcing a consistent case as well.
The rest of the IPv6 notation toolkit.
Paste any IPv6 address and get the full 128-bit form, the hextet breakdown, the canonical short form and the address type — free, and with no sign-up.