How IPv4 Addresses Are Encoded Inside IPv6 and How Compression Works
An IPv4-to-IPv6 converter shows the standardised ways an IPv4 address can be represented inside the much larger IPv6 format, and it compresses or expands IPv6 addresses between their shorthand and full forms. The important thing to understand first is that an IPv4 address cannot literally become an IPv6 address — they are different address spaces, 32 bits versus 128 bits. What the tool produces are agreed-upon encodings that let dual-stack software, tunnels, and translators carry an IPv4 address through an IPv6 world. Network engineers running mixed IPv4/IPv6 environments, developers reading dual-stack socket logs, and students learning the transition mechanisms all reach for a converter like this to make sense of the several different notations.
Each encoding serves a distinct purpose. An IPv4-mapped IPv6 address, written ::ffff:192.168.1.1 or in hex as ::ffff:c0a8:0101, is how a dual-stack socket represents an incoming IPv4 connection internally, so a single IPv6 socket can accept both families. The IPv4-compatible form ::192.168.1.1 is deprecated by RFC 4291 and should not be used, but the tool shows it and labels it clearly so you recognise it in old configurations. The 6to4 prefix 2002:c0a8:0101::/48 (RFC 3056) embeds the IPv4 address into a routable IPv6 prefix for automatic tunnelling. NAT64 uses the well-known prefix 64:ff9b::/96 (RFC 6052) to let IPv6-only clients reach IPv4-only servers through a translator. The tool also compresses IPv6 to its RFC 5952 canonical form — lowercase hex with the single longest run of zero groups collapsed to a double colon — and expands it back to eight full groups.
Walk through 192.168.1.1. Its four octets pair into two 16-bit hex groups: 192 and 168 become c0a8, and 1 and 1 become 0101, trimmed to 101. So the IPv4-mapped hex form is ::ffff:c0a8:101, the dotted form is ::ffff:192.168.1.1, the 6to4 prefix is 2002:c0a8:101::/48, and the NAT64 form is 64:ff9b::192.168.1.1. On the compression side, the address 2001:db8:0:0:0:0:0:1 has six consecutive zero groups in the middle; RFC 5952 says to replace the single longest run with ::, giving the canonical 2001:db8::1. Expanding it back restores every group: 2001:0db8:0000:0000:0000:0000:0000:0001. The loopback ::1 expands to seven zero groups followed by 0001.
Engineers deploying dual-stack web servers see IPv4-mapped addresses in their access logs and need to recognise that ::ffff:203.0.113.5 is simply an IPv4 client reaching an IPv6-listening socket, not a separate host. Teams running IPv6-only mobile networks rely on NAT64 to reach the still-large IPv4-only internet, and reading the 64:ff9b:: prefix in a packet capture confirms translation is happening. Anyone migrating firewall rules from IPv4 to a dual-stack ruleset uses the mapped form to keep an IPv4 allowlist meaningful inside IPv6 match statements. Documentation writers compress long IPv6 addresses to the canonical form so configuration examples stay readable and match what modern tools output.
The pitfall worth internalising is that these are encodings, not a magic conversion: none of them makes an IPv4-only host reachable over native IPv6 by itself — that still requires a tunnel endpoint or a translator actually running somewhere. A second common slip is compressing IPv6 incorrectly by collapsing more than one zero run to double colons, which is ambiguous and invalid; RFC 5952 permits exactly one :: per address, always applied to the leftmost longest run, and this tool follows that rule so its output is always canonical and parseable. A related detail is that when two zero runs are equally long, the rule breaks the tie by compressing the leftmost one, which is why some tools that pick the rightmost run produce a technically valid but non-canonical address that fails string comparisons in configuration audits. Every parse and encoding step runs locally in your browser as pure arithmetic and string work, so no address you enter is ever uploaded or stored anywhere, making the tool safe for internal addressing documentation.
