IPv6 विस्तारित और संकुचित करें

What the IPv6 Expand & Compress tool does

IPv6 addresses can be written many ways that all mean the same 128-bit value, and that flexibility is exactly what makes them hard to read and compare. This tool takes an IPv6 address in any legal form and gives you two canonical answers: the fully expanded address, with all eight 16-bit groups and every leading zero spelled out, and the fully compressed address in the standard RFC 5952 short form. Feed it 2001:db8::1 and it expands to 2001:0db8:0000:0000:0000:0000:0000:0001; feed it that long version back and it compresses to 2001:db8::1. It also understands addresses that embed an IPv4 tail (like ::ffff:192.168.0.1) and strips a zone index such as %eth0 before parsing. You use it whenever two addresses that should match refuse to, or when a config file, ACL, or database demands one consistent notation.

How it works technically

An IPv6 address is 128 bits, written as eight groups of four hexadecimal digits (each group is 16 bits) separated by colons. The double colon :: is shorthand for “one or more consecutive groups of all zeros,” and it may appear only once, because otherwise the address would be ambiguous. To expand, the tool splits the address on ::, counts the groups on each side, inserts exactly enough 0000 groups in the middle to reach eight total, and pads every group to four digits. To compress, it applies the RFC 5952 rules that make an address canonical: hexadecimal is lowercase, leading zeros in each group are removed, and the single longest run of consecutive zero groups is replaced by :: — with the leftmost run winning any tie, and a run of just one zero group left uncompressed. Any embedded IPv4 portion is first converted to two hex groups so the arithmetic stays uniform. The parser rejects malformed input: more than one ::, the wrong number of groups, or an IPv4 octet above 255.

Concrete examples and use cases

• fe80::1 — a link-local address expands to fe80:0000:0000:0000:0000:0000:0000:0001, handy when a tool insists on the full form.
• 2001:0DB8:0000:0000:0000:0000:0000:0001 — upper-case and zero-padded from one vendor, compresses to the tidy 2001:db8::1 another vendor expects.
• Reverse DNS — building an ip6.arpa PTR record requires the fully expanded nibble-by-nibble form, which the expander gives you directly.
• ACLs and firewalls — normalizing both sides of a comparison prevents rules that silently never match because one address was compressed and the other was not.

Practical tips and gotchas

The most common mistake is trying to use :: twice or using it to stand for a single zero group where the canonical form would not — both make an address non-standard even if some parsers tolerate it. Case matters for tidiness but not for value: 2001:DB8::1 and 2001:db8::1 are the same address, and RFC 5952 asks for lowercase, which is what this tool emits. When an address carries a prefix (like 2001:db8::/32) or a zone identifier (fe80::1%eth0), keep those separate in your mind — the tool normalizes the address part and drops the zone before parsing. And remember that :: at the very start or end still counts as the zero run, so ::1 is the loopback and :: alone is the unspecified all-zeros address.

Privacy: every expansion and compression is computed locally in your browser by JavaScript. The address you type stays on your device — nothing is sent to a server, uploaded, or logged — so internal and production IPv6 addresses are safe to work with here. If you are rolling out IPv6 and want to make sure your real connection is not leaking outside an encrypted tunnel, our VPN is built to prevent exactly that kind of exposure.