An IPv6 address only converts to IPv4 when it carries one inside. Paste it and the converter reads the embedded 32 bits: ::ffff:c000:201 gives 192.0.2.1, 64:ff9b::c000:221 gives 192.0.2.33, and 2002:c000:204::1 gives 192.0.2.4. A native address such as 2001:db8::1 has no IPv4 equivalent, and the tool says so.
Server logs, firewall rules and DNS64 answers often show IPv4 clients wearing an IPv6 disguise. A dual-stack socket logs 192.0.2.1 as ::ffff:192.0.2.1, a NAT64 gateway hands out 64:ff9b::c000:221, and an old 6to4 or Teredo tunnel hides the IPv4 inside the prefix or bit-inverted at the end. This converter expands each address, recognises which of those five formats it is, and prints the IPv4 address with the type next to it. Paste a single address or a whole column of them, one per line, or open a text file. The limit is fundamental: most IPv6 addresses are assigned natively and contain no IPv4 at all, so there is nothing to translate and no lookup can invent one.
Type or paste IPv6 addresses one per line, or open a .txt or .csv file from your device.
The headline shows the IPv4 for the first line and its address type.
Every line gets a row with its IPv4, or Invalid, or None embedded for native IPv6.
The steps show each address fully expanded and which bits were read.
Result IPv4 address (first line): 192.0.2.45
Address type: Teredo (2001::/32)
Lines with an IPv4 inside: 1
Lines read: 1
The client IPv4 is stored bit-inverted in the last 32 bits; flipping every bit back gives 192.0.2.45.
Result IPv4 address (first line): 192.0.2.33
Address type: NAT64 (64:ff9b::/96)
Lines with an IPv4 inside: 1
Lines read: 1
The well-known prefix 64:ff9b::/96 wraps the IPv4 in its last 32 bits, here c000:0221.
Result IPv4 address (first line): 192.0.2.1
Address type: IPv4-mapped
Lines with an IPv4 inside: 2
Lines read: 4
A mapped and a 6to4 address both yield IPv4; the documentation address 2001:db8::1 is native IPv6 and the last line is skipped.
IPv4 = bits 96–127 (mapped, compatible, NAT64); bits 16–47 (6to4); bits 96–127 XOR ffffffff (Teredo client)
::ffff:0:0/9664:ff9b::/962002::/162001::/32Each line is expanded to eight 16-bit groups, filling :: with zeros and folding a trailing dotted quad into two groups. The prefix decides where the IPv4 sits. Mapped, compatible and NAT64 addresses keep it in the last two groups; 6to4 keeps it in groups two and three; Teredo stores the client address with every bit flipped, so the tool inverts it back. Anything else is reported as native IPv6.
A server listening on an IPv6 socket that also accepts IPv4 reports IPv4 clients as IPv4-mapped addresses. The client really connected over IPv4; the last 32 bits are its address.
No. IPv6 has 128 bits and IPv4 has 32, so only addresses built to carry an IPv4 can be reversed. A native global address such as one from your ISP has no IPv4 inside it.
It is the NAT64 well-known prefix. A DNS64 resolver synthesises these addresses for IPv4-only sites so IPv6-only clients can reach them through a translator. The last 32 bits are the site's real IPv4 address.
RFC 4380 stores the client's public IPv4 in the last 32 bits with every bit inverted, so 3fff:fdd2 becomes 192.0.2.45 after an XOR with ffff:ffff. The Teredo server's IPv4 sits unmodified in the third and fourth groups.
No. The ::a.b.c.d form was deprecated by RFC 4291 in 2006. The tool still decodes it because old configurations and textbooks show it, and labels it as deprecated.
Yes. Square brackets from URLs, a /64-style prefix length and a %eth0 zone suffix are stripped before the address is parsed.