Why does the canonical IPv6 form use lowercase letters and one specific compression?

RFC 5952 (Kawamura & Kawashima, 2010) tightens RFC 4291 by mandating one textual form per address, removing ambiguity that had broken string-equality comparisons across systems. §4.3 requires lowercase hex ('a' through 'f', not 'A' through 'F'). §4.2.3 mandates :: compress the longest run of consecutive 16-bit zero fields; when two runs tie, the first one wins. §4.2.2 forbids using :: to elide a single zero field. So 2001:DB8:0:0:0:0:0:1 must canonicalise to 2001:db8::1 — not 2001:db8:0:0::1 or 2001:DB8::1. Tools that fail to canonicalise inputs frequently mis-compare addresses or duplicate firewall entries; the converter normalises every IPv6 input to the §4 form before showing the alternative representations.

What's the difference between RFC 1918 private space and the 100.64.0.0/10 CGNAT range?

RFC 1918 (Rekhter et al., 1996) reserved 10/8, 172.16/12, and 192.168/16 for organisations using NAT — these ranges are routable inside an enterprise but never on the public internet. ISPs hit a problem as IPv4 exhaustion approached: their customer routers already used RFC 1918 ranges internally, so the carrier-side NAT layer needed a different range to avoid collisions when both endpoints used 10/8. RFC 6598 (Weil, Kuarsingh, Donley, Liljenstolpe & Azinger, 2012) carved 100.64.0.0/10 out of the unallocated v4 space specifically for that ISP-CGNAT tier. A packet may traverse three layers of NAT: customer LAN (RFC 1918) → ISP CGNAT (RFC 6598 100.64/10) → public internet. Tools that only flag RFC 1918 as 'private' miss the 100.64/10 carrier scope, which is why the converter highlights both.

Are class A, B, and C still meaningful?

Functionally, no. The 1981 IPv4 specification (RFC 791) introduced classful addressing — class A reserved 1.0.0.0–127.255.255.255 with an 8-bit network mask, B 128–191 with /16, C 192–223 with /24, plus class D for multicast and class E reserved. As routing tables exploded in the early 1990s, the IETF deprecated the classful scheme and replaced it with CIDR (Classless Inter-Domain Routing). The original CIDR documents (RFC 1518/1519, September 1993) defined the variable-length prefix system; RFC 4632 (Fuller & Li, 2006) is the current canonical specification. Modern routers, allocators, and registries do not use classes; addresses are described by /CIDR alone. The terminology survives in legacy curriculum, some Cisco IOS commands ('ip classless'), and shorthand among engineers who learned in that era.

Why does my IP show up as a giant integer in MySQL or Cloudflare logs?

MySQL's INET_ATON('192.168.1.1') returns 3232235777 — the four octets read as a big-endian 32-bit unsigned integer (192*16777216 + 168*65536 + 1*256 + 1). The integer form takes 4 bytes in storage versus 15 characters for the dotted string, and integer comparisons run faster than string ops against indexed columns. INET_NTOA(3232235777) reverses the conversion. Cloudflare logs and BigQuery exports follow the same big-endian-integer pattern. IPv6 needs 16 bytes — INET6_ATON returns a binary blob, not a single Long. Network order (big-endian) is the canonical wire format defined for IP fields in RFC 791; tools that read packet captures or socket buffers see those bytes directly, while applications that handle IP addresses as integers may need POSIX htonl()/ntohl() conversions on hosts whose CPU stores integers in little-endian. The converter shows both the dotted-decimal and the integer alongside hex/binary so operators can cross-reference log dumps without manual math.

IP Address Converter

Q: Why does my IPv6 address show as ::ffff:192.168.1.1 in some logs?

That's an IPv4-mapped IPv6 address, defined in RFC 4291 §2.5.5.2 (Hinden & Deering, 2006). The prefix ::ffff:0:0/96 lets a dual-stack socket receive both IPv4 and IPv6 connections on a single AF_INET6 file descriptor — when an IPv4 client connects, the kernel synthesises this textual form so the application can treat the address uniformly. Java in particular surfaces these mappings: InetAddress.getByName("192.168.1.1") may stringify as /192.168.1.1 but bind() returns it as ::ffff:c0a8:0101 on a v6 socket. Logs that mix v4 and v6 traffic on the same listener show this form for everything the kernel mapped, which surprises engineers the first time they see it. The underlying address is still the 32-bit IPv4 value; only the textual form changed.

Input Detected: Decimal

Enter an IP in any format: decimal dotted, binary, hex (0xC0A80101 or C0.A8.01.01), or integer.

Conversions

Decimal ?

192.168.1.1

Binary ?

11000000.10101000.00000001.00000001

Hexadecimal ?

C0.A8.01.01

Integer ?

3232235777

Octal ?

300.250.001.001

IPv4-Mapped IPv6 ?

::ffff:192.168.1.1

About this tool

An IP address is a 32-bit unsigned integer (IPv4) or 128-bit (IPv6). Both can be written multiple ways without changing the underlying bits. Dotted decimal (192.168.1.1) is the canonical IPv4 form; integer (3232235777), hexadecimal (0xC0A80101), binary (11000000.10101000.00000001.00000001), and octal forms are alternative encodings of the same value, encountered in log files (MySQL INET_ATON), Cisco IOS configs, BPF filters, and firewall rule expressions. IPv6 has its own canonical text form defined by RFC 5952 (Kawamura & Kawashima, 2010): lowercase hex digits MUST be used per §4.3, the longest run of consecutive 16-bit zero fields MUST be compressed with :: per §4.2.3, and :: MUST appear at most once. This tool converts between formats client-side — no input leaves your browser — and surfaces the IPv4-mapped IPv6 representation (::ffff:0:0/96, RFC 4291 §2.5.5.2) used by dual-stack systems to embed v4 addresses inside v6 sockets. Private ranges, CGNAT shared space, and IPv6 ULA are flagged in the output for quick context.

How to convert IP formats

Enter an IP address in any supported format — dotted-decimal (192.168.1.1), 32-bit integer (3232235777), hexadecimal (0xC0A80101), binary, octal, or IPv6 short-form (::1).
The tool detects the input format, validates it, and presents every other representation simultaneously.
Copy individual values for use wherever your target system expects a specific form (firewalls, log queries, legacy router CLIs).
Switch the radio between IPv4 and IPv6 modes when the source data uses the other family.

Common use cases

Translating a 32-bit integer IP from a MySQL log back into dotted-decimal for a firewall rule.
Reading binary netmasks printed by a routing-table dump as human-readable /CIDR or dotted-form.
Preparing addresses for systems that demand a specific representation (Cisco IOS hex, MySQL INET_ATON integer, Windows ipconfig dotted).
Teaching the relationship between dotted-decimal, host-order integer, and network-order bytes when introducing IP addressing.

Frequently asked questions

Why does my IPv6 address show as ::ffff:192.168.1.1 in some logs?

It's an IPv4-mapped IPv6 address (RFC 4291 §2.5.5.2). Dual-stack sockets receive both v4 and v6 traffic on a single AF_INET6 file descriptor; the kernel synthesises this textual form so the application code can treat addresses uniformly.

Why does the canonical IPv6 form use lowercase letters?

RFC 5952 §4.3 requires lowercase hex, §4.2.3 mandates :: compress the longest run of zero fields, §4.2.2 forbids :: for a single zero field. The rules remove ambiguity that broke string-equality across systems.

What's the difference between RFC 1918 private and 100.64.0.0/10 CGNAT?

RFC 1918 (10/8, 172.16/12, 192.168/16) is for organisations behind NAT. RFC 6598 100.64/10 was carved out specifically for ISP-side carrier-grade NAT to avoid collisions when both ends already use 10/8.

Are class A, B, C still relevant?

Functionally no. CIDR (Classless Inter-Domain Routing) deprecated classful addressing in 1993; RFC 4632 (Fuller & Li, 2006) is the canonical spec. Classes survive in legacy curriculum and a handful of Cisco IOS commands.

Why does my IP appear as a giant integer in MySQL or Cloudflare logs?

MySQL's INET_ATON('192.168.1.1') returns 3232235777 — the four bytes read as a 32-bit unsigned integer. Smaller storage, faster indexed comparisons. INET_NTOA reverses the conversion.

What the formats actually encode — and why CGNAT, ULA, and class A/B/C show up

The dotted-decimal 192.168.1.1 is purely a typographic convention: each octet is a byte rendered in decimal between 0 and 255. The single integer 3232235777 is the same four bytes interpreted as a big-endian 32-bit unsigned integer. Hexadecimal 0xC0A80101 shows the bytes in base 16. None carries different routing semantics — they all yield the identical 32-bit value in IP headers. Endianness becomes relevant at the C-API boundary: BSD sockets define POSIX htonl()/ntohl() to convert between host-order integers and network-order bytes (big-endian on the wire) when applications handle IP fields directly. Private ranges layered. RFC 1918 (Rekhter, Moskowitz, Karrenberg, de Groot & Lear, 1996) reserved 10.0.0.0/8, 172.16.0.0/12, and 192.168.0.0/16 for use behind NAT. Carrier-grade NAT needs a separate reservation because RFC 1918 ranges are already in use inside customer networks; RFC 6598 (Weil, Kuarsingh, Donley, Liljenstolpe & Azinger, 2012) allocated 100.64.0.0/10 specifically for ISP-side CGNAT. RFC 4193 (Hinden & Haberman, 2005) defined the IPv6 equivalent fc00::/7, with FD00::/8 as the locally-assigned, pseudo-random half. Class A/B/C addressing was deprecated in 1993 by the original CIDR proposal; RFC 4632 (Fuller & Li, 2006) is the current canonical specification, obsoleting RFC 1519. The class concept survives only in legacy curriculum and a handful of unmodernised configurations.

Auto-detects input format from any supported notation (dotted-decimal, integer, hex, binary, octal, IPv6 short-form)
Decimal dotted, binary, hexadecimal (0x prefix), 32-bit integer, octal
IPv4-mapped IPv6 display (::ffff:a.b.c.d, RFC 4291 §2.5.5.2)
RFC 1918 / RFC 6598 / RFC 4193 range flagging in output
Copy each value individually
Conversion is pure client-side math (no upload)

Free. No signup. Browser tools (subnet, JWT, password strength) run locally; lookup tools query public APIs (Cloudflare DoH, RDAP, certificate logs). Full per-tool breakdown at /methodology/.

Sources (9)

Kawamura, S., & Kawashima, M. (2010). A Recommendation for IPv6 Address Text Representation. RFC 5952, IETF.
Hinden, R., & Deering, S. (2006). IP Version 6 Addressing Architecture. RFC 4291, IETF (§2.5.5.2 IPv4-Mapped IPv6 Address).
Postel, J. (1981). Internet Protocol. RFC 791, IETF (§3.2 classful addressing).
Rekhter, Y., Moskowitz, B., Karrenberg, D., de Groot, G. J., & Lear, E. (1996). Address Allocation for Private Internets. RFC 1918, IETF.
Weil, J., Kuarsingh, V., Donley, C., Liljenstolpe, C., & Azinger, M. (2012). IANA-Reserved IPv4 Prefix for Shared Address Space. RFC 6598, IETF (100.64.0.0/10 CGNAT).
Hinden, R., & Haberman, B. (2005). Unique Local IPv6 Unicast Addresses. RFC 4193, IETF (fc00::/7 with FD00::/8 locally-assigned half).
Rekhter, Y., & Li, T. (1993). An Architecture for IP Address Allocation with CIDR. RFC 1518, IETF (deprecated by RFC 4632).
Fuller, V., Li, T., Yu, J., & Varadhan, K. (1993). Classless Inter-Domain Routing (CIDR): an Address Assignment and Aggregation Strategy. RFC 1519, IETF (obsoleted by RFC 4632).
Fuller, V., & Li, T. (2006). Classless Inter-domain Routing (CIDR): The Internet Address Assignment and Aggregation Plan. RFC 4632, IETF (current canonical, obsoletes RFC 1519).

These are the IETF RFCs, NIST publications, and W3C standards the tool implements or queries. Locate them on the IETF Datatracker (datatracker.ietf.org) or the official standards body.