IPv6 Expander |
IPv6 address expansion reverses the two compression rules defined in RFC 5952: it restores
all leading zeros in each of the eight 16-bit hextets and replaces the ::
double-colon notation with the full sequence of all-zero hextets. The result is the
complete 128-bit address in RFC 4291 §2.2 preferred notation — eight groups of four
lowercase hexadecimal digits separated by colons, always 39 characters including separators.
| Property | Value |
|---|---|
| Governing standard (full notation) | RFC 4291 §2.2 (February 2006) |
| Governing standard (compression) | RFC 5952 §4 (August 2010) |
| Expanded form length | Always 39 characters (8 groups × 4 hex digits + 7 colons) |
| Hex digit case in expanded form | Lowercase (consistent with RFC 5952 §4.3 precedent) |
| Address value changes on expansion | No — only the text representation changes |
Enter a compressed IPv6 address and get the complete eight-hextet form instantly.
2001:db8::1
or fe80::1. For multiple addresses, switch to Bulk List mode and enter one address per line.
2001:0db8:0000:0000:0000:0000:0000:0001.
The expanded form and the compressed form represent the same 128-bit address. Only the text encoding differs. The table below shows the two forms for the same address and explains what expansion restores in each hextet.
| Format | Example | Length |
|---|---|---|
| Compressed (RFC 5952) | 2001:db8::1 | 2–39 chars (variable) |
| Expanded (RFC 4291 §2.2) | 2001:0db8:0000:0000:0000:0000:0000:0001 | Always 39 chars |
| Loopback (compressed) | ::1 | 3 chars |
| Loopback (expanded) | 0000:0000:0000:0000:0000:0000:0000:0001 | 39 chars |
| Google DNS (compressed) | 2001:4860:4860::8888 | 20 chars |
| Google DNS (expanded) | 2001:4860:4860:0000:0000:0000:0000:8888 | 39 chars |
IPv6 addresses are 128-bit identifiers represented as eight 16-bit groups (hextets)
in hexadecimal notation, as specified in RFC 4291 §2.2 (February 2006).
The full notation requires each hextet to be written with exactly four hex digits,
zero-padded from the left — for example, db8 becomes 0db8.
RFC 5952 (August 2010) standardized a compressed canonical form for use in
configuration files, DNS AAAA records (RFC 3596), and human-readable contexts.
It applies two rules: (1) leading zeros within each hextet are suppressed,
and (2) the longest consecutive run of all-zero hextets is replaced with
:: — used at most once per address, with the leftmost run
selected when runs are equal in length (§4.2.3).
Expansion reverses both rules exactly: every hextet is zero-padded to four digits,
and the :: is replaced with the correct number of 0000
groups to produce exactly eight hextets total. The number of restored groups
equals 8 − (groups left of ::) − (groups right of ::).
Why machines need the full form: two compressed representations
of the same address (2001:db8::1 and 2001:0db8::0001)
are not equal as strings, but are equal as 128-bit values. Systems that compare
IPv6 addresses as strings — including many database indices, ACL parsers,
and log correlation engines — require the canonical expanded form to avoid
false mismatches.
Do it yourself
Python's built-in ipaddress module (available since Python 3.3)
provides the .exploded property, which returns the RFC 4291 §2.2
full notation directly:
python3 -c "import ipaddress; print(ipaddress.ip_address('2001:db8::1').exploded)"
# Output: 2001:0db8:0000:0000:0000:0000:0000:0001For bulk expansion of a file with one address per line:
python3 -c "
import ipaddress, sys
for line in sys.stdin:
line = line.strip()
if line:
print(ipaddress.ip_address(line).exploded)
" < addresses.txt$ip = [System.Net.IPAddress]::Parse("2001:db8::1")
$bytes = $ip.GetAddressBytes()
[string]::Join(":", (0..7 | ForEach-Object {
$bytes[$_ * 2].ToString("x2") + $bytes[$_ * 2 + 1].ToString("x2")
}))
# Output: 2001:0db8:0000:0000:0000:0000:0000:0001python3 << 'EOF'
import ipaddress
addresses = ["2001:db8::1", "fe80::1", "::1"]
for addr in addresses:
print(ipaddress.ip_address(addr).exploded)
EOF
The .exploded property in Python's ipaddress module
implements RFC 4291 §2.2 exactly. The PowerShell approach uses
System.Net.IPAddress.GetAddressBytes() to access the 16-byte
binary representation and formats each pair of bytes as a 4-character hex group.
Both produce identical output to this tool for all valid IPv6 addresses.
Database storage and deduplication.
A backend developer inserting IPv6 addresses into a PostgreSQL text
column finds that 2001:db8::1, 2001:0db8::1, and
2001:0db8:0000:0000:0000:0000:0000:0001 are stored as three distinct
strings representing the same address. Normalizing all addresses to full expanded
form before insertion ensures exact-match deduplication, consistent indexing, and
reliable WHERE address = ? queries.
Firewall ACL and routing configuration. A network engineer writing an access control list on a Cisco IOS XE or Juniper device encounters a rule that never fires despite matching the intended source. The ACL was written using compressed notation, but the packet header contains the full form. Expanding both the rule and the expected value to RFC 4291 §2.2 notation and comparing them directly identifies the mismatch before deployment.
SIEM log correlation. A security analyst correlating events across multiple log sources — Apache, nginx, and an IDS — finds that the same source address is written in three different compressed forms across the three systems. Expanding all addresses to full notation before importing into the SIEM ensures that all events from the same host are grouped together in timeline analysis, preventing missed correlations.
2001:db8::1 becomes 2001:0db8:0000:0000:0000:0000:0000:0001:
all leading zeros are restored in each of the eight 16-bit hextets, and the
double-colon (::) notation is replaced with the explicit all-zero groups it represents.
2001:db8::1 and
2001:0db8:0::1) are not equal as strings, causing duplicate entries or
missed deduplication. Second, firewall ACL rules on appliances that perform exact string
matching rather than semantic IPv6 parsing. Third, regular expressions and log analysis:
writing regex patterns for compressed IPv6 is complex; expanded form allows consistent
pattern matching across all log entries.
:: — for
example, 2001:db8::1. Expanded IPv6 (RFC 4291 §2.2 full notation) restores
all leading zeros and all zero hextets explicitly — for example,
2001:0db8:0000:0000:0000:0000:0000:0001. Both representations describe the
exact same 128-bit address; only the text encoding differs.
:: sequences, or has more than eight hextet groups),
the tool returns an explicit error rather than silently producing a wrong result.
:: sequences — only
one is allowed per address per RFC 4291; (2) the address has more than eight colon-separated
groups; (3) a group contains non-hexadecimal characters. An already fully-expanded address
(39 characters, no ::) is also valid input — the tool will return it unchanged
with leading zeros normalized. IPv4-mapped IPv6 addresses in the form
::ffff:192.0.2.1 are not supported by this tool.