Skip to content
Lizely

IPv4 to IPv6 Converter

Convert a strict IPv4 address into RFC 4291 IPv4-mapped IPv6 mixed, compressed hexadecimal, and fully expanded forms with exact bit placement.

Privacy: your files never leave your device. All processing happens locally in your browser.

How to use

  1. 1.Enter one strict dotted-decimal IPv4 address without spaces or a CIDR suffix.
  2. 2.Create the RFC 4291 IPv4-mapped representation.
  3. 3.Choose mixed, compressed hexadecimal, or expanded hexadecimal notation for the destination.
  4. 4.Parse and normalize the copied value with the destination platform before using it in policy or production configuration.

About IPv4 to IPv6 Converter

IPv4 to IPv6 Converter creates the RFC 4291 IPv4-mapped IPv6 representation of one strict dotted-decimal IPv4 address. Enter a value such as 192.0.2.1 and receive three equivalent text forms: mixed notation ::ffff:192.0.2.1, compressed hexadecimal ::ffff:c000:201, and the fully expanded 0000:0000:0000:0000:0000:ffff:c000:0201 form. Each output carries the same 128 bits. Separate copy controls make it clear which spelling enters a configuration file, test, database, or diagnostic note.

An IPv4-mapped IPv6 address is not an arbitrary conversion and is not a new globally routable IPv6 address. RFC 4291 defines 80 zero bits, followed by 16 one bits written as FFFF, followed by the original 32 IPv4 bits. The form is used by APIs and dual-stack software to represent an IPv4 node inside an IPv6-sized address structure. It does not allocate native IPv6 space, configure a route, translate packets, or make an IPv4-only service reachable through the public IPv6 Internet.

The three displays differ only in notation. Mixed form keeps the final 32 bits as familiar dotted decimal. Compressed hexadecimal converts each pair of IPv4 octets into one 16-bit word and removes leading zeroes in those words. Expanded form pads all eight 16-bit groups to four hexadecimal digits. Lowercase hexadecimal is used consistently for copy-friendly canonical-style output. Systems may normalize the same bits to another equivalent spelling, so compare parsed addresses or normalized forms rather than raw text when equality matters.

Input follows the same strict rules as Python's modern ipaddress library: exactly four decimal octets from 0 through 255, no surrounding spaces, signs, shorthand, hexadecimal notation, CIDR suffix, or leading zeroes. Rejecting 192.00.2.1 avoids legacy octal ambiguity. Hostnames are not resolved because resolution introduces network dependence and can change over time. Paste the numeric address you intend to represent, and classify its scope separately if a policy distinguishes private, loopback, multicast, documentation, or globally reachable ranges.

Do not confuse IPv4-mapped addresses with the deprecated IPv4-compatible form, 6to4 addresses, NAT64 prefixes, SIIT translation, DNS64 synthesis, or ordinary IPv6 subnet assignments. Those mechanisms have different prefixes and operational meaning. RFC 4291 explicitly deprecates the old compatible form and separately defines the mapped FFFF marker. This tool deliberately emits only mapped addresses so a generic Convert button cannot silently choose a deployment mechanism. Network architecture decisions still belong to an operator who understands the local stack and transition design.

Application behavior varies. Some socket APIs expose an IPv4 peer as an IPv4-mapped IPv6 address when an IPv6 listener accepts both protocol families. Access-control lists, logs, databases, proxies, and frameworks may normalize, preserve, or reject the mixed form. Test the exact consumer and avoid assuming that a string prefix check is sufficient for authorization. Parse addresses with a maintained library, normalize before comparison, and account for mapped IPv4 semantics when applying private, loopback, denylist, or rate-limit rules.

The converter runs locally, performs no lookup, and stores nothing. Eight external fixtures cover zero, one, private, loopback, documentation, and maximum IPv4 values. Tests assert mixed and compressed results, plus the complete expanded form and invalid boundaries. For production code, cross-check results with the destination platform's IP-address library and record whether it expects mapped addresses at all. If the goal is subnet planning, native IPv6 assignment, or translation service configuration, use standards and tools designed for that separate task rather than treating this representation as connectivity.

Methodology & sources

Validates four strict decimal octets, combines each octet pair into the low-order two 16-bit hexadecimal words, prefixes 80 zero bits and FFFF exactly as RFC 4291 specifies, and renders mixed, compressed, and expanded text forms.

Frequently asked questions

Does this give my host native IPv6 connectivity?
No. It only represents an IPv4 address inside the RFC 4291 mapped 128-bit format; routing and translation require separate network configuration.
Why are there three different outputs?
They are equivalent spellings of the same 128 bits: mixed dotted decimal, compressed hexadecimal, and fully expanded hexadecimal.
Is this the same as NAT64 or 6to4?
No. Those are different transition mechanisms with different prefixes and operational behavior. This tool emits IPv4-mapped addresses only.

Related tools

Developer Tools guides

View all