Advertisement
All 8 hextets · address type · RFC 5952 canonical form

IPv6 Expander
Full Form, Every Hextet

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 ::.

Nodemaven

Enter any IPv6 address — compressed or already expanded. You get the full form, every hextet, and the address type.

Advertisement
Robert Harrison, OSINT and Network Utility Expert, on expanding and compressing IPv6 addresses at TrustMyIP.com
Written & Verified By

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 Robert
Advertisement

What Is IPv6 Expand and How Does Our IPv6 Expander Work?

When 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.

Why Do You Need to Expand IPv6 Addresses?

There are several critical reasons to use an IPv6 full address converter:

  • Database Storage: Storing expanded addresses ensures consistent indexing and prevents duplicate entries from different compressed representations of the same address.
  • Firewall Rules: Security systems often require exact string matching. You need to normalize IPv6 to ensure rules match correctly.
  • Regex Pattern Matching: Writing regular expressions for compressed IPv6 is extremely complex. Expanded addresses simplify pattern matching.
  • Log Analysis: When analyzing network logs, consistent formatting from IPv6 expansion prevents missing related events.
  • Network Debugging: Engineers use the IPv6 full form to identify subnet boundaries and troubleshoot routing issues.

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.

How to Expand IPv6 Address: Step-by-Step Guide

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:

Step 1: Find the Double Colon (::)

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.

Step 2: Count Visible Hextets

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.

Step 3: Calculate Missing Zero 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.

Step 4: Replace :: With Zero Hextets

Insert the calculated number of 0000 hextets where :: appears. Our example becomes: 2001:db8:0000:0000:0000:8a2e:370:7334.

Step 5: Add Leading Zeros

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.

IPv6 Uncompress vs Expand vs Unshorten: Understanding the Terms

You will encounter several terms when working with IPv6 address conversion. Here is what each means:

IPv6 Expand

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.

IPv6 Uncompress

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.

IPv6 Unshorten

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.

IPv6 Normalize

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.

Common IPv6 Addresses: Compressed and Full Forms

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.

Understanding the 128-Bit IPv6 Structure

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.

Network Prefix: First 64 Bits

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.

Interface Identifier: Last 64 Bits

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.

IPv4 vs IPv6: Why Expansion Tools Are Necessary

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.

Address Size Comparison

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.

Notation Differences

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.

IPv4

  • • 32 bits (4 octets)
  • • ~4.3 billion addresses
  • • Decimal notation
  • • No compression needed
  • • Requires NAT for sharing

IPv6

  • • 128 bits (8 hextets)
  • • 340 undecillion addresses
  • • Hexadecimal notation
  • • Compression essential
  • • Every device gets unique IP

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.

The Short Form Beside It: What RFC 5952 Calls Canonical

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

Four rules, and they are MUST, not SHOULD

This is worth stating precisely, because a lot of published guidance softens it. RFC 5952 uses MUST in all four places:

  • Leading zeros must go. Section 4.1: “Leading zeros MUST be suppressed”, and a single all-zero group “MUST be represented as 0”.
  • The :: 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.
  • Never use :: 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.
  • Lower case. Section 4.3 requires the letters 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.

Which form do you want?

Use the When
Expanded formSorting 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 formConfiguration 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.
EitherTyping 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.

The Two Standards Behind All of This

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 — what an IPv6 address is

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.

RFC 5952 — how to write one

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.

Frequently asked questions about expanding IPv6 addresses

What does it mean to expand an IPv6 address?

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 ::.

How do I expand an IPv6 address with :: by hand?

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.

Why does the result also show a shortened form?

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.

What is the IPv6 full form of ::1?

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.

Is 2001:DB8::1 wrong, or just different?

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.

How many characters are in an expanded IPv6 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.

Why does the tool also tell me the address type?

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.

Can I link to this tool with an address already filled in?

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.

Is the address I paste sent anywhere?

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.

Expand, uncompress, unshorten, decompress — are these different things?

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.

Related IPv6 and network tools

The rest of the IPv6 notation toolkit.

Have another address to expand?
All eight hextets, and what kind it is

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.