IPv6 to IPv4 Converter
Find the IPv4 inside, or find out there isn’t one
Paste an IPv6 address and this converter reads out the IPv4 address embedded in it — mapped, NAT64, 6to4, Teredo or ISATAP — from the exact bit positions the relevant RFC defines. Most IPv6 addresses contain no IPv4 address at all, and for those it says so instead of doing arithmetic on 32 bits that mean something else.
Convert an IPv6 address to IPv4
One address per line, up to 100. Brackets, a port, a zone id and a prefix length are all accepted and reported back. The result is labelled either detected, meaning the address itself proves what it carries, or calculated, meaning you supplied the missing prefix length.
Quick answer: how do you convert IPv6 to IPv4?
You extract it, and only if it is there. Check the prefix first: ::ffff: means the last 32 bits are the IPv4 address, 64:ff9b:: means NAT64, 2002: means the 32 bits after it are a 6to4 site, 2001:0: means Teredo with the client address stored inverted. Anything else almost certainly holds no IPv4 address, and no arithmetic will produce one.
Robert Harrison
OSINT & Network Utility Expert
Robert covers DNS, ports, SSL, subnet and CIDR maths and the address-format converters on TrustMyIP. He also wrote our guide to Teredo addresses and the connection errors they cause.
Three implementations of this decoder were written independently — the JavaScript on this page, one in Python and one in Go — and compared column by column over 36,265 addresses with no difference anywhere. Where Python’s standard library has its own decoder for a mechanism, it was used as a fourth opinion and had to agree in both directions. The system C library then had to confirm the bits. Two places where this page spells an address differently from that C library are named, counted and explained below, because neither changes a single bit.
Published 25 September 2026 · last reviewed 25 September 2026 · More from Robert
Most IPv6 Addresses Contain No IPv4 Address At All
IPv6 to IPv4 conversion only works when there is something to convert. IPv6 is not a re-encoding of IPv4: it is a separate 128-bit address space with its own allocations, and a normal address handed out by an ISP or a hosting provider carries no IPv4 address at any offset. If you want the background on how the two families relate, our plain-English guide to IP addresses covers it, and the story of why the second family exists at all is in the piece on running out of IPv4 addresses.
That matters here because the arithmetic will happily lie to you. Take the last 32 bits of 2606:4700::6810:85e5 and read them as four octets and you get 104.16.133.229. It looks like a real address, and nothing about it is reserved or special — this tool’s own registry check calls it ordinary globally reachable unicast space. It has nothing to do with the input, and nothing about the input suggested those 32 bits were an IPv4 address in the first place.
The test that matters: an IPv6 address only carries an IPv4 address when its prefix says so. Seven transition mechanisms embed one deliberately, and five of those seven live in a prefix IANA has registered for exactly that purpose. The sixth is a deprecated form with no registered prefix at all, and the seventh is a pattern any prefix can carry — which is why the tool treats those two differently. Outside a registered prefix, extracting an IPv4 address is not conversion; it is reading random bits.
So this page does two jobs. When the address does carry an IPv4 address, it reads it out of the bit positions the standard defines, names the standard, and says what the address was for. When it does not, it says which block the address belongs to instead, and stops. Being told “there is nothing in here” is the correct answer far more often than most converters admit.
Detected or Calculated: How to Read Your Result
Every result carries one of two labels, and the difference between them is the whole point of the page.
Detected means the address itself is the evidence. It sits in a registered prefix whose layout an RFC fixes, so the IPv4 address comes out of known bit positions with nothing assumed. Calculated means you supplied the missing piece — a NAT64 prefix length — and the answer is arithmetic conditional on that being right. The tool will never quietly promote the second into the first.
Why a NAT64 address needs a length you have to know
NAT64 is the one mechanism where the prefix is chosen by whoever runs the network. RFC 6052 section 2.2 allows six lengths — /32, /40, /48, /56, /64 and /96 — and the address does not record which one was used. The Well-Known Prefix 64:ff9b::/96 is defined as a /96 and nothing else, so those decode cleanly. Anything on an operator's own prefix does not.
How the tool rules lengths out without guessing
There is a rule that helps, and it is a MUST rather than a convention. RFC 6052 reserves bits 64 to 71 — the octet it calls u — and says those bits “MUST be set to zero”. For five of the six allowed lengths that octet falls inside the part the translator writes, so a non-zero value there is proof the address did not come from a translator using that length. For a /96 the prefix covers those bits, so nothing is ruled out.
How much that helps depends on the address in front of you. Whenever bits 64 to 71 are not zero — that is, whenever the fifth group does not begin with 00 — five of the six candidates die at once and /96 is the only arithmetically consistent reading left. When those bits happen to be zero, nothing is ruled out and all six readings survive. Either way the table shows every length, the address each would produce, and the reason the dead ones are dead.
The bits after the IPv4 address are handled differently, because the standard treats them differently: RFC 6052 says the suffix “SHOULD be set to zero”. A non-zero suffix is reported as a hint against that length and never as a disqualification. If you want the reverse operation — building these addresses rather than taking them apart — the IPv4 to IPv6 converter does that, with the same six lengths.
How to Extract an IPv4 Address from IPv6: Every Mechanism That Embeds One
Each mechanism puts the 32 bits somewhere different, and each is defined by its own document. The tool checks all seven on every address, and reads 6rd as well when you supply its two parameters.
IPv4-mapped — ::ffff:a.b.c.d
Eighty zero bits, then sixteen one bits, then the IPv4 address. This is what fills server logs with ::ffff: prefixes: an IPv4 client reached a socket listening on IPv6, and the operating system wrapped the address so a single dual-stack code path handles both families. RFC 4291 section 2.5.5.2 defines it, and the IANA registry marks the prefix as not a valid source, not a valid destination and not forwardable. It is a notation, not a route.
IPv4-compatible — ::a.b.c.d, deprecated
The same idea with zeros where the ffff sits. RFC 4291 section 2.5.5.1 deprecated it, and its “prefix” is 96 zero bits, which is not a registered address-embedding prefix at all. The tool still reads it, because it turns up in old configuration files, but it labels the reading a convention rather than a proof, and runs the result through the IPv4 registry so ::2 comes back as part of 0.0.0.0/8 rather than as somebody's host.
NAT64 — 64:ff9b::/96 and 64:ff9b:1::/48
RFC 6052 has names for both halves of this: the result is an IPv4-embedded IPv6 address, and an operator’s own translation prefix is a Network-Specific Prefix. The Well-Known Prefix is a fixed /96, so an address inside it decodes with no assumptions; a Network-Specific Prefix does not, which is the whole reason for the length table. The RFC 8215 local-use block is a /48, and an operator inside it may run stateless translation on a /48, /56, /64 or /96, so the tool reports the block with certainty and lists every reading rather than picking one. That block exists so those restrictions do not apply: RFC 8215 section 3 records that RFC 6052 section 3.1 “imposes certain restrictions on the use of the WKP, such as forbidding its use in combination with private IPv4 addresses”. One more piece of vocabulary worth knowing, from RFC 7915: an address range that represents IPv4 systems inside IPv6 space holds IPv4-converted addresses, while an IPv6 system whose own address maps algorithmically back to a slice of the provider’s IPv4 pool has an IPv4-translatable address. The bit layout is the same in both directions, which is why one reader handles both. A good background read on the address family itself is our beginner's guide to IPv6 addresses.
Finding your own NAT64 prefix with ipv4only.arpa
RFC 7050 turns the problem around, and RFC 8880 updates it — that is the document which makes the name formally special-use, and the one the IANA registry credits for both addresses. The name ipv4only.arpa resolves to two fixed IPv4 addresses, 192.0.0.170 and 192.0.0.171; asking for its A record on 25 September 2026 returned exactly those two. Ask a DNS64 resolver for the AAAA record instead and it answers with them embedded in the network’s translation prefix — RFC 7050 calls that prefix Pref64 — so finding one inside an address reveals the prefix and its length. On a network with no DNS64 the AAAA query returns nothing at all, and that absence is itself the answer. Paste a synthesised answer here and the tool reports the prefix. You can run either query with our DNS lookup tool.
6to4 — 2002::/16
Sixteen bits of 2002 followed by the whole 32-bit IPv4 address, per RFC 3056 section 2, which also gives each site a /48. The IPv4 must be a public address; the section says it “MUST NOT be a private address”. RFC 7526 deprecated the public anycast relay at 192.88.99.0/24 and moved two RFCs to Historic, but it explicitly did not deprecate 2002::/16, so these addresses still decode.
Teredo — 2001::/32, everything inverted
The richest of the seven. After the prefix come the Teredo server's IPv4 address in the clear, a 16-bit flags field, the client's UDP port and the client's IPv4 address — the last two stored with every bit flipped. The tool un-inverts both and decodes each RFC 5991 section 3.1 flag field separately. Our guide to Teredo addresses covers why they appear and the connection problems they cause.
ISATAP — a pattern, not a proof
ISATAP puts 0000:5efe or 0200:5efe in the interface identifier, followed by the IPv4 address. The only difference between the two is the u bit, which RFC 5214 section 6.1 sets to 1 when the embedded IPv4 address is globally unique and 0 when it is not — so the tool prints it, and flags the contradiction when a u bit of 1 sits in front of a private address. RFC 7136 is the later Standards Track document and says identifier bits carry no general meaning, so the bit is reported rather than trusted. And because the pattern lives in the identifier and not the prefix, any /64 can carry it, which is why this reading is labelled lower confidence with the measured chance of an accidental match beside it.
6rd — the one that cannot be fully reversed
RFC 5969 strips IPv4MaskLen high-order bits from the customer’s IPv4 address before placing the remainder in the delegated prefix. With a non-zero mask those bits are not in the address at all, so the full IPv4 cannot be recovered from it. The tool recovers what is present, says how many bits that is, and joins the halves only if you supply the provider prefix holding the rest.
When the Extracted IPv4 Proves the IPv6 Address Was Built Wrong
Extracting the address is only half the value. Running it through the IANA IPv4 Special-Purpose Address Registry is the other half, because several of these mechanisms place rules on which IPv4 addresses they may carry — and a result that breaks one of those rules tells you the address you pasted should never have existed.
A non-global address inside the NAT64 Well-Known Prefix
RFC 6052 section 3.1 is blunt about this: the Well-Known Prefix “MUST NOT be used to represent non-global IPv4 addresses”, and a translator receiving such a packet “MUST drop” it. So 64:ff9b::10.1.2.3 is not merely unusual. It is an address a conforming translator is required to discard, and the tool says so rather than printing 10.1.2.3 as though it were a normal result.
A private address inside a 6to4 prefix
The same class of fault under a different rule. RFC 3056 section 2 requires the embedded IPv4 address to be public, so 2002:c0a8:101::1 decodes to 192.168.1.1 and is flagged as an invalid 6to4 prefix in the same breath.
A Teredo address that cannot work
Three separate contradictions get reported here. A server address that is not globally reachable cannot be a Teredo server, because RFC 4380 section 2.3 defines one as a node reachable through a globally routable IPv4 address. A client address that is not global contradicts section 2.11, which defines that field as the global address a NAT presents to the internet. And a z bit that is not zero breaks RFC 5991 section 3, which says it MUST be zero.
None of these checks needs a network request, because none of them is a lookup — they are all rules about which numbers may sit in which positions. If you want to know who actually holds an address you extracted, that is a different question and a different tool: take it to the IP lookup and ask the registries.
Converting IPv6 to IPv4 Manually, and on the Command Line
Every extraction here is four bytes read out of a known offset, so it is easy to do yourself once you can see the bits. Take 2001:db8:122:344:c0:2:2100:0, which came from a /64 translation prefix.
- Write the address out in full, eight groups of four hex digits:
2001:0db8:0122:0344:00c0:0002:2100:0000. Our RFC 5952 canonical-form tool writes any address out in full for you, and names the rule that shortened it in the first place. - Count bits. Each group is 16 bits, so group 1 covers bits 0–15, group 5 covers bits 64–79, and so on.
- Skip the prefix. A /64 prefix is groups 1 to 4, so the interesting part starts at group 5.
- Skip the reserved octet. Bits 64 to 71 are the first two hex digits of group 5 — here
00, as the standard requires. - Take the next 32 bits:
c0, then group 60002, then the first two digits of group 7,21. That givesc0 00 02 21. - Convert each byte to decimal:
0xc0is 192,0x00is 0,0x02is 2,0x21is 33. The answer is192.0.2.33.
The command line confirms the easy cases and not the interesting ones. Measured on a Linux host on 25 September 2026: getent hosts ::ffff:8.8.8.8 printed 8.8.8.8 dns.google, and getaddrinfo handed the same literal back as ::ffff:8.8.8.8 with its dotted tail intact — but handed back 64:ff9b::808:808 for the NAT64 form, without one. Python’s ipaddress module decodes mapped, 6to4 and Teredo addresses on its own. ping from iputils 20240117 refused every one of these literals outright with “Address family for hostname not supported”, so it is not the tool for this. And nothing standard decodes NAT64 at an arbitrary prefix length, ISATAP or 6rd, which is why this page exists.
# what the C library will tell you: it prints a mapped address dotted
python3 -c 'import ipaddress; print(ipaddress.IPv6Address("::ffff:c000:221").ipv4_mapped)'
# and it decodes 6to4 and Teredo, but nothing else on this page
python3 -c 'import ipaddress; print(ipaddress.IPv6Address("2002:c000:221::1").sixtofour)'
# the two fixed addresses, which any resolver returns
dig A ipv4only.arpa +short
# your NAT64 prefix - EMPTY unless the network runs DNS64
dig AAAA ipv4only.arpa +short
One spelling difference is worth knowing about, because it will make two tools look like they disagree when they do not. RFC 5952 section 5 allows the dotted tail only where a well-known prefix identifies the last 32 bits as an IPv4 address. The C library dots the deprecated ::a.b.c.d form, which does not qualify, and refuses to dot 64:ff9b::a.b.c.d, which does — RFC 6052 prints it dotted in its own worked example. This page follows the standards in both cases. The bits are identical either way, and both divergences were counted during testing. RFC 5952 has a recorded internal tension nearby: erratum 4900, held for a future document update, notes that its own sections disagree over whether a single zero group may be compressed — the rule RFC 6052’s printed /64 example breaks.
What This Tool Cannot Tell You
The limits are as useful as the results, so they are listed rather than buried.
- It does no lookup of any kind. No DNS, no WHOIS, no geolocation, no reverse pointer. Everything on the page comes from the 128 bits you typed and from published registries built into the file.
- It cannot tell you the IPv4 address of an IPv6-only host. If a name publishes only an AAAA record there is no IPv4 address to find, and arithmetic cannot invent one.
- It cannot confirm a NAT64 prefix length. It can rule lengths out, and it will tell you which and why, but the surviving candidate is still a candidate.
- ISATAP is a pattern match, not a proof, and the page says so on every ISATAP result along with the measured false-positive rate.
- 6rd cannot be fully reversed whenever IPv4MaskLen is above zero. The missing high-order bits are not in the address.
- The Teredo port and flag fields have no third-party decoder anywhere to check against. They are verified by round trip, against the RFC diagrams, and by three implementations written independently — which is not the same as a library oracle.
- No Ahrefs data informed this page, and no traffic, adoption or prevalence figure appears on it, because none has been measured.
One more, about scope rather than capability: the tool reports what an address is, not whether it is currently reachable. A 6to4 address decodes perfectly and may still be unroutable, because the public relay infrastructure it depended on was withdrawn. Decoding tells you how an address was built; only a packet tells you whether it works.
Frequently Asked Questions About IPv6 to IPv4 Conversion
How do I convert an IPv6 address to IPv4?
Only if the IPv6 address was built to carry an IPv4 address in the first place. Paste it above: if it sits in a prefix that IANA has registered for mapping, NAT64, 6to4, Teredo or ISATAP, the tool reads the IPv4 out of the exact bit positions the relevant RFC defines. If it does not, there is nothing to extract, and the tool says so rather than doing arithmetic on 32 bits that mean something else entirely.
Does every IPv6 address contain an IPv4 address?
No, and this is the single most common misunderstanding about the two protocols. IPv6 is a separate 128-bit address space, not a re-encoding of IPv4. A normal address your ISP or hosting provider assigns — something like 2606:4700::6810:85e5 — has no IPv4 address inside it at any offset. Only a handful of transition mechanisms deliberately embed one, and those are recognisable because each lives in its own registered prefix.
What does ::ffff: in front of an IP address mean?
It is the IPv4-mapped form from RFC 4291 s2.5.5.2, and it means an IPv4 client reached a socket that was listening on IPv6. The operating system hands your application the IPv4 address wrapped this way so one code path handles both families. Strip the ::ffff: and you have the real client address. IANA records it as unusable on the wire — no source, no destination, not forwardable — so it never travels anywhere.
How do I find the IPv4 inside a NAT64 address?
You need the prefix length, and the address does not record it. RFC 6052 allows six: /32, /40, /48, /56, /64 and /96. The Well-Known Prefix 64:ff9b::/96 is fixed at /96, so those decode with no guessing. For any other prefix the tool prints all six readings and uses the reserved octet at bits 64 to 71 — which s2.2 says MUST be zero — to rule out the lengths that are arithmetically impossible.
Is the IPv4 in a Teredo address the client’s real address?
It is the address the client’s NAT presents to the internet, not the machine’s private address. RFC 4380 s2.11 defines that field as “a global IPv4 address” produced by translating the client’s own address through one or more NATs. It is stored inverted — the RFC says “each bit in the address and port number is reversed” — and so is the UDP port, so the tool un-inverts both and shows you the outside of the NAT plus the port it had open.
Can I get the IPv4 address of an IPv6-only website?
Not from the address, and not from this tool. If a site publishes only an AAAA record it has no IPv4 address to find, and no amount of arithmetic on its IPv6 address will invent one. What sometimes exists is the other way round: a translator on your network synthesising IPv6 addresses for IPv4-only servers. Reaching an IPv6-only host from an IPv4-only network needs a translator or a proxy, not a converter.
Related address and network tools
The converter that goes the other way, and the rest of the address-format family.
Need to build one of these addresses instead?
The converter that goes the other way produces every form an IPv4 address can take, names the RFC behind each, and says which can carry traffic.
Last updated 25 September 2026. Every rule on this page comes from the RFC that defines it; the address classifications come from the IANA IPv4 and IPv6 Special-Purpose Address Registries, both read on 25 September 2026 and both dated 9 October 2025 by IANA. Nothing you type leaves your browser.