IPv6 Expander

Expand and canonicalise IPv6 addresses

Paste a compressed IPv6 address such as 2001:db8::1 and see its fully expanded eight-group form plus the canonical RFC 5952 compressed form. This is handy when configuring firewalls, ACLs or DNS records that need the full, unambiguous address, and for verifying two addresses are actually the same.

How it works

The tool first validates the input — only one :: is permitted, each hextet must be 1–4 hex digits, and the total must resolve to eight groups. To expand, it replaces the :: with enough 0000 groups to reach eight, then left-pads each group to four digits. To compress to RFC 5952 canonical form, it lowercases the hex, drops leading zeros in each group, and replaces the longest run of two or more zero groups with ::.

Example

Everything runs locally in your browser; nothing is uploaded.

When you actually need this tool

IPv6 compression rules — the :: shorthand, the dropped leading zeros — exist to make addresses readable for humans. But many network tools, security systems, and databases store or compare addresses in a single canonical form. If two representations of the same address are stored differently, a string comparison finds no match even though they are identical hosts. Common scenarios where expansion or canonicalization is essential:

• Firewall ACL debugging. An IP blocked in the ruleset as ::ffff:192.0.2.1 might arrive in logs as 0000:0000:0000:0000:0000:ffff:c000:0201 — the same address, but a naive string match fails. Expanding both to their full 128-bit form reveals the match.
• DNS AAAA record verification. Some DNS tools display the address in full expanded form; your configuration might use the compressed form. Expanding both lets you confirm they resolve to the same host.
• Security log analysis. SIEM platforms and intrusion detection systems sometimes normalize IPv6 addresses differently from your router or firewall. Expanding both to the full form is the only reliable way to compare across tools.
• Code that compares IPs. If you are writing backend code that checks an incoming IPv6 against an allowlist, always normalize to the RFC 5952 canonical form before comparing — never compare raw strings from user input against stored values.

More address examples

The third example illustrates an important RFC 5952 rule: when there are multiple runs of zeros of equal length, the :: replaces the first such run, not the last.

Common validation errors and what they mean

If your input fails, the tool flags which rule was violated so you can correct the address without guessing.