IPv4 to IPv6 Converter
Every form your address really has

There Is No “IPv6 Version” of Your IPv4 Address

This is the first thing to get straight, because almost every converter online skips it. An IPv4 address is 32 bits. An IPv6 address is 128. You cannot turn one into the other any more than you can turn a phone number into a postal address — there is no mathematical relationship waiting to be discovered. IPv6 is a different protocol with its own header, its own routing and its own allocations, not a re-encoding of IPv4. If you want to see how different, the IPv4 versus IPv6 header comparison puts the two side by side.

So there is no IPv4 to IPv6 conversion in the sense the phrase suggests. What does exist is a small set of standard ways to carry those 32 bits inside a 128-bit address. Each one was invented for a specific job during the long transition between the two protocols, each is defined by its own RFC, and each behaves differently. Some never leave the inside of a program. One only works if a translator is running. One gives you a whole network rather than a single address. That is why this tool returns six rows instead of one, and why every row is labelled.

So if you came here asking what is the IPv6 equivalent of my IP address, the useful answer is a question back: equivalent for what? To put in a config file that wants an IPv6 literal for an IPv4 host? To reach an IPv4 server from an IPv6-only network? To get an IPv6 prefix for a site that only has IPv4? Those are three different answers, and they are the three sections below. Your own actual IPv6 address, the one that carries your traffic, comes from your ISP or your hosting provider — not from arithmetic on your IPv4.

For the format itself, our beginner’s guide to what an IPv6 address is starts from first principles, and what an IP address is and how it works is the place to begin if any of this is new. If you want to understand why any of these transition mechanisms exist at all, IPv4 address exhaustion is the short version.

How to Read Your Result

Every row in the result carries four things: the name of the form, the address itself, the RFC and section that define it, and — the part no other converter gives you — whether it can actually be used. Here is the whole set at a glance.

The three lines under each result

Every row gives the same 128 bits up to three times, because different places want different spellings. The first line is the canonical form — the one to write down. The second, when there is one, is the other legal spelling, labelled with the reason it exists. The third, marked Expanded, is all eight groups padded to four digits with nothing left out, which is what you want when you are lining addresses up in a config file or comparing them by eye. If you only need one of those jobs, the IPv6 compressor and IPv6 expansion tools do the compressed and expanded forms on their own.

Two spellings, one address

Several rows show a second line marked as an alternative. That is not a different address — it is the same 128 bits written another way. RFC 5952 settles how an IPv6 address should be written down, and one of its rules, in section 5, is that a dot-decimal tail like ::ffff:192.0.2.33 is only for prefixes that are well known to carry an embedded IPv4. Two qualify: ::ffff:0:0/96 and 64:ff9b::/96. Everything else gets the all-hex spelling, so the deprecated compatible form is written ::c000:221 here. Implementations genuinely disagree about that one, and it is worth knowing which does what, because all three were measured before this page shipped: the system C library prints it dotted as ::192.0.2.33, while Go 1.24 and Python’s ipaddress both keep it in hex, as we do. All three agree on using dots for the IPv4-mapped form. Both spellings are given on every row, so you can copy whichever one the thing you are configuring expects.

The Six Forms, One by One

They are not interchangeable. Picking the wrong one is the usual reason a converted address “does not work”, so it is worth knowing what each is actually for.

IPv4-mapped — ::ffff:a.b.c.d

This is the one you have almost certainly already seen, even if you did not know its name. Eighty zero bits, then ffff, then the IPv4 address. It exists for a single practical reason: a program can open one IPv6 socket and handle both families, because the operating system hands it every IPv4 client in this form. That is why an access log suddenly shows ::ffff:203.0.113.9 instead of 203.0.113.9, and why ::ffff:127.0.0.1 turns up in local testing next to plain old 127.0.0.1.

The critical detail is that it is not a network address. The SANS Internet Storm Center put it plainly in March 2026: “IPv4-mapped IPv6 addresses are not used on the network, but instead, translated to IPv4 before a packet is sent.” The same diary notes the security consequence — a filter that compares addresses as text will not recognise ::ffff:203.0.113.9 as the address it already blocked. If you keep an allowlist or a rate limiter, normalise before you compare.

NAT64 with the Well-Known Prefix — 64:ff9b::a.b.c.d

This is the form that matters most in 2026, because it is the one modern networks actually build. RFC 6052 reserves 64:ff9b::/96 so that any IPv6-only host can construct a destination for an IPv4-only server without being told a local prefix first. The packet goes to a translator at the network edge, which rewrites it to IPv4 and sends the answer back the other way. Paired with DNS64, which synthesises AAAA records for IPv4-only names, it is how an IPv6-only phone reaches the parts of the internet that never moved.

This is current, not historical. When Red Hat shipped a CLAT in NetworkManager 1.58 with RHEL 10.3 in July 2026, the description was exactly this operation: the host “creates a synthetic IPv6 destination address by embedding the target IPv4 address into the well-known NAT64 prefix”. If you are debugging an IPv6-only or “IPv6-mostly” network, this row is the one you want.

NAT64 with the local-use prefix — 64:ff9b:1::/48

Added later, by RFC 8215 in 2017, and almost unknown outside operator circles. It reserves 64:ff9b:1::/48 “for local use within domains that enable IPv4/IPv6 translation mechanisms” — a block an operator can carve up for its own translators without borrowing space from its production allocation. There is one practical difference from the well-known prefix, and it is the reason both rows are shown: the well-known prefix must not carry a private IPv4 address, and this one may. That is covered in the section on refusals below.

6to4 — 2002:V4ADDR::/48

The odd one out, because it does not give you an address at all. RFC 3056 s2 lays out the prefix as sixteen bits of 2002, then your entire 32-bit IPv4, then a 16-bit subnet field and a 64-bit interface identifier. The result is a /48: one public IPv4 address earns a site 65,536 IPv6 subnets, derived automatically with nothing to register. That was an elegant idea when IPv6 allocations were hard to get.

Two things to know. First, the IPv4 must be public — the RFC says it “MUST be duly allocated to the site by an address registry… and it MUST NOT be a private address”. Second, 6to4 needed a relay to reach the rest of IPv6, and the free public relay service is gone: RFC 7526 deprecated the anycast relay prefix 192.88.99.0/24 in 2015 and moved the relevant RFCs to Historic. What it did not do — and this is widely misreported — is deprecate the mechanism. That document states that “the basic unicast 6to4 mechanism defined in RFC 3056 and the associated 6to4 IPv6 prefix 2002::/16 are not deprecated”. The addresses remain valid; what vanished was the free ride. To plan the subnets inside a /48, take the prefix to the subnet calculator or the CIDR calculator.

ISATAP — 0000:5efe or 0200:5efe

ISATAP produces an interface identifier, not a complete address: the bottom 64 bits, which you then attach to whatever /64 the link uses. RFC 5214 s6.1 builds it from the IANA OUI 00-00-5E, the byte 0xFE, and the 32-bit IPv4 — and one bit of it is decided by the address itself. “When the IPv4 address is known to be globally unique, the ‘u’ bit (universal/local) is set to 1; otherwise, the ‘u’ bit is set to 0.” So a public IPv4 gives 0200:5efe and a private one gives 0000:5efe. The tool applies that rule for you rather than making you choose, and also shows the identifier on fe80::/64, which is where you will actually see it.

Two caveats worth saying plainly, because they change how much weight to put on this row. First, RFC 5214 is an Informational document published through the Independent Submission stream: the RFC itself carries the notice that it is not endorsed by the IETF and has no formal standing in the standards process. It is a record of a mechanism, not a standard.

Second, the u bit no longer means what RFC 5214 assumed. RFC 7136 (Standards Track, February 2014) updates the addressing architecture and says of interface identifiers that “in all cases, the bits in an IID have no generic semantics; in other words, they have opaque values”, and that the u bit is “not a reliable indicator of universal uniqueness”. So the tool still sets it the way RFC 5214 s6.1 says to, because that is how an ISATAP identifier is constructed — but do not read anything into it elsewhere.

IPv4-compatible — ::a.b.c.d

The same shape as IPv4-mapped but with zeros where the ffff goes. It belongs to the earliest transition thinking and RFC 4291 s2.5.5.1 retired it in 2006: “The ‘IPv4-Compatible IPv6 address’ is now deprecated because the current IPv6 transition mechanisms no longer use these addresses.” It is in the results for one reason only — it still appears in old configuration files and old documentation, and you need to be able to identify it. Do not write a new one.

Teredo — and why this row is usually empty

Teredo tunnels IPv6 over UDP so a host stuck behind NAT can still get IPv6. Its address, per RFC 4380 s4, packs four separate things into 128 bits: the 2001:0000::/32 prefix, the Teredo server’s IPv4 address in the clear, a 16-bit flags field, and then the client’s UDP port and IPv4 address — both stored inverted. The RFC describes the inversion exactly: “an exclusive OR of the 16-bit port number with the hexadecimal value 0xFFFF, and an exclusive OR of the 32-bit address with the hexadecimal value 0xFFFFFFFF”.

Three of those four values are not present in your IPv4 address, which is why no honest tool can produce a Teredo address from one. Fill in the optional server, port and flags fields above and this converter will build exactly the address those inputs describe; leave them blank and it will tell you why the row is missing rather than inventing a server.

There is a further reason a built Teredo address will not match a live one, and it is the part other explanations leave out. RFC 5991 (Standards Track, September 2010) updates RFC 4380 and redefines that 16-bit flags field as six separate fields: the cone bit C, a bit z that “MUST be set to zero when the address is constructed”, the universal/local and group bits U and G, and two random fields — Random1 of four bits and Random2 of eight. Those twelve bits MUST be set to a random value. The reason is given in the RFC: an attacker who learns the client’s mapped address and port “would still need to attack a range of 4,096 IPv6 addresses to determine the actual Teredo IPv6 address of the client”.

So a conforming client’s address is unpredictable by design. The same RFC also tells clients to skip the first qualification phase and use “the Teredo link-local address with the cone bit set to zero”, and tells peers that they “SHOULD ignore the cone bit in the address of a Teredo peer and treat it as if it were always clear”. The flags field here therefore takes a raw hexadecimal value rather than an on/off switch, the result decodes every field for you, and the tool tells you when what you entered contradicts RFC 5991. One more constraint: RFC 4380 s2.3 defines a Teredo server as “a node that has access to the IPv4 Internet through a globally routable address”, so a private or reserved server address is flagged. If a Teredo address is causing you trouble, Robert’s guide to Teredo addresses and the connection errors they cause is the practical one.

NAT64 on Your Own Prefix: Six Lengths and One Easy Mistake

If your network runs its own translator it will use its own prefix, not the well-known one. RFC 6052 calls that a Network-Specific Prefix, and RFC 6052 s2.2 allows exactly six prefix lengths for it, and the IPv4 address sits in a different place in each. The awkward part is that the 32 bits are not always contiguous: bits 64 to 71 are reserved and must be zero, so for four of the six lengths the address is split in two around them.

Those six results are not our examples — they are the ones printed in Table 1 of RFC 6052 itself, which makes them ideal for checking an implementation. This tool reproduces all of them, plus Table 2 for the well-known prefix.

Anything else is accepted, because an operator may translate on any prefix it controls — but the tool checks what you typed against the IANA IPv6 Special-Purpose Address Registry and says so when the block is registered for something else. Type 2002::/32 and it will point out that 2002::/16 is 6to4 space; type 2001:db8:122:344::/96 and it will note that 2001:db8::/32 is documentation space under RFC 3849, fine for an example and not for a real network.

Where this tool and RFC 6052’s table differ, and why

One row above is worth explaining, because a careful reader will spot it. Table 1 of the RFC prints the /64 result as 2001:db8:122:344:c0:2:2100::, with a :: at the end. This tool prints 2001:db8:122:344:c0:2:2100:0 instead.

Both are the same 128 bits. The difference is which writing rule you follow. RFC 5952 s4.2.2 is explicit: “The symbol ‘::’ MUST NOT be used to shorten just one 16-bit 0 field.” The RFC 6052 table has exactly one zero field at the end, so :: there breaks that rule. There is no conflict between the standards, though: RFC 6052 s2.4 says its representation conforms to RFC 4291 s2.2, the earlier and looser rule, which did allow it. RFC 5952 came later and tightened it. We follow RFC 5952 because that is what the site’s IPv6 compressor follows, and because Python’s ipaddress module prints it the same way. Both spellings were checked against each other bit for bit before this page shipped.

For context on the wider family of translation mechanisms — DNS64, 464XLAT, the CLAT on your phone — the terminology is worth knowing but this is a converter, not a tutorial: if you need the IPv6-only side of a name rather than an address, the DNS lookup tool will show you whether a host publishes a real AAAA record in the first place.

Doing the IPv4 to IPv6 Conversion by Hand

It is worth doing once, because after that the output of any converter stops being magic. Take 192.0.2.33, the address RFC 6052 uses in its own examples.

1. Write each octet in hex, two digits each. 192 is c0, 0 is 00, 2 is 02, 33 is 21. So the 32 bits are c0000221.
2. Split that into two groups of four hex digits. c000 and 0221. These are the last two groups of the IPv6 address.
3. Put them behind the prefix you want. For IPv4-mapped the prefix is eighty zero bits then ffff, so the full address is 0000:0000:0000:0000:0000:ffff:c000:0221.
4. Compress it. Drop the leading zeros in each group and replace the longest run of zero groups with ::, giving ::ffff:c000:221. Because this prefix is one RFC 5952 recognises, you may also write the tail in dotted decimal: ::ffff:192.0.2.33.
5. For NAT64, change only the prefix. 64:ff9b:: then the same two groups: 64:ff9b::c000:221, or 64:ff9b::192.0.2.33.
6. For 6to4, all 32 bits go in the middle. 2002, then c000, then 0221, then nothing: 2002:c000:221::/48.

Checking your hex against the command line is easy, and it is a good habit:

If you need the same 32 bits in other bases rather than inside IPv6, IP to hex gives you step 1 on its own, and IP to binary shows the individual bits. How to read an IP address format covers the notation from the beginning.

When the Tool Refuses, and Which Rule It Is Enforcing

Most converters will happily give you an address that no network will ever accept. This one refuses in three situations, and each time it tells you the rule rather than just failing.

A non-global IPv4 in the NAT64 Well-Known Prefix

This is not a style preference. RFC 6052 s3.1 says: “The Well-Known Prefix MUST NOT be used to represent non-global IPv4 addresses… Address translators MUST NOT translate packets in which an address is composed of the Well-Known Prefix and a non-global IPv4 address; they MUST drop these packets.” So 64:ff9b::192.168.1.1 is not merely unusual — a conforming translator is required to throw it away. The tool refuses it and points you at the 64:ff9b:1::/48 row instead, which is exactly the prefix RFC 8215 reserved for local translation.

A private or reserved IPv4 in 6to4

RFC 3056 s2 requires the embedded address to be a real allocation: it “MUST be duly allocated to the site by an address registry (possibly via a service provider) and it MUST NOT be a private address” — the RFC points at RFC 1918 for what counts as private. A 6to4 prefix built on 10.0.0.0/8 could never be reached, because no relay could route back to it. The same applies to the IPv4-compatible form, where RFC 4291 s2.5.5.1 says the address “must be a globally-unique IPv4 unicast address”.

“Non-global” here is not our judgement. The tool checks the address against the IANA IPv4 Special-Purpose Address Registry and uses that registry’s own Globally Reachable column — which is why five special-purpose blocks are still allowed through, including 192.0.0.9/32 and 192.0.0.10/32, which sit inside the otherwise non-global 192.0.0.0/24. When a row is refused, the result names the exact registry entry and its RFC.

An address with leading zeros

Type 010.1.1.1 and the tool stops rather than guessing, because implementations genuinely disagree about what it means. Six of them were run against that exact string before this page shipped. The old inet_aton family reads a leading zero as octal, so it returns 08010101 — the address 8.1.1.1, not 10.1.1.1. Every modern parser tested refuses it outright instead: inet_pton, PHP’s filter_var and ip2long, Python’s ipaddress, Node’s net.isIPv4, and Go’s net.ParseIP and netip.ParseAddr. So the choice is between silently producing an address four bytes different from the one you meant, and stopping. This tool stops and names the rule. Web browsers were not tested and nothing is claimed about them. The IP to octal tool goes into why this is a security problem as well as a parsing one.

Where You Actually Meet These Addresses

Four situations account for almost every visit to an IPv4 to IPv6 converter, and only one of them is what the phrase sounds like.

Your logs filled up with ::ffff:

You moved a service to a dual-stack listener and every IPv4 client now arrives wrapped. Nothing is broken, but anything that compares addresses as strings — an allowlist, a rate limiter, a per-IP counter, a GeoIP lookup — will treat ::ffff:203.0.113.9 and 203.0.113.9 as two different clients. Normalise on the way in. If you need to pull the addresses out of a log file first, the IP extractor and the IP sorter handle both families.

You are debugging an IPv6-only or IPv6-mostly network

A client cannot reach an IPv4-only service and you need to know what address it is really sending to. Build the NAT64 form for the IPv4 in question, then check whether that is what appears in the capture. If it is not, the problem is DNS64 or the CLAT rather than the translator.

Something wants an IPv6 literal and you only have IPv4

A configuration file, a test fixture, a library that insists on AF_INET6. The IPv4-mapped form is almost always the right answer here, and it is the first row for that reason. Generating a batch of them for test data? The random IP generator will give you the IPv4 side.

You found an unfamiliar address and want to know what it is

That is the opposite direction, and it will be its own tool: IPv6 to IPv4 takes an address apart and recovers the IPv4 inside it, including the obfuscated one in a Teredo address. In the meantime, the IPv6 compressor already identifies which special-purpose prefix an address belongs to.

What This Tool Does Not Do

Stated plainly, because a converter that pretends to be complete is worse than one that admits its edges.

• It does not give you a routable IPv6 address. Nothing can. A usable IPv6 address is assigned to you by an ISP or a hosting provider. Every row here is either a notation, a translation artefact, or a prefix that needs infrastructure behind it.
• It does not check whether anything works. No DNS query, no ping, no reachability test — it runs entirely in your browser and makes no network calls at all. Whether a NAT64 translator exists on your path is not something arithmetic can answer.
• It does not accept a range or a CIDR block. One address per line. For prefix maths use the subnet calculator, the CIDR calculator or binary to IP — all three are in the grid below.
• It does not guess Teredo values. Without a server address and a port there is no row, by design.
• It does not work the other way round. Extracting an IPv4 from an IPv6 address is a different job with different edge cases; that is IPv6 to IPv4.
• MAP-E, MAP-T, DS-Lite and 6rd are not here. Those mechanisms embed IPv4 too, but each needs operator-specific parameters — a rule set, a domain, a sharing ratio — that cannot be derived from an address. Producing a number for them without those inputs would be guessing.
• The ISATAP row has no library to check it against. Neither Python nor Go nor the C library has an ISATAP decoder, so while that row was rebuilt independently in two other languages and all three agree, all three are still our reading of the bit diagram in RFC 5214 s6.1 rather than someone else’s implementation. Both u-bit cases were checked by hand.
• The Teredo row cannot match a live client, and that is not a bug. RFC 5991 requires twelve of the sixteen flag bits to be random, so the tool can only build the address your inputs describe — not the one a particular machine is actually using.
• The layout has not been opened in a real browser. The arithmetic was checked under Node and the page itself was driven inside a DOM implementation — typing, pressing Convert, reading the result back — so the wiring is tested. But no part of this build has been viewed in Chrome, Safari or Firefox, which means layout at real widths, web fonts and the actual clipboard permission prompt are unverified. The copy button falls back to selecting the text if the clipboard call is refused.
• Bulk mode is capped at 200 addresses, because performance on a phone with a very long list was not profiled.

Frequently Asked Questions About IPv4 to IPv6 Conversion