IPv4 Address Converter

The four representations of an IPv4 address

An IPv4 address is a 32-bit integer. The familiar dotted-decimal form (192.168.1.1) is just one way to display those 32 bits, split into four 8-bit octets and rendered in base 10. The exact same address can be written as a single decimal integer (3232235777), in hexadecimal (0xC0A80101 or C0.A8.01.01), or as a binary string. All four representations are interchangeable; they're just different bases on the same number.

192.168.1.1
    │   │   │ └─ 0x01 = 00000001
    │   │   └─── 0x01 = 00000001
    │   └─────── 0xA8 = 10101000
    └─────────── 0xC0 = 11000000

→ as 32-bit integer:  192 × 2^24 + 168 × 2^16 + 1 × 2^8 + 1  =  3 232 235 777
→ as hex:             C0A80101
→ as binary:          11000000.10101000.00000001.00000001

When you actually need these conversions

• Database storage. Storing IPs as 32-bit integers (PostgreSQL INET or BIGINT, MySQL UNSIGNED INT) is 4 bytes vs 7–15 for the string. For tables with billions of rows this matters; INET_ATON() in MySQL and inet_aton() in PostgreSQL do the conversion.
• Range queries. "All addresses in 10.0.0.0/8" becomes a simple WHERE ip BETWEEN 167772160 AND 184549375 when IPs are stored as integers. Much faster than string comparisons or LIKE patterns.
• Bit manipulation for subnet calculations. Testing whether an address belongs to a subnet is one bitwise AND when both are integers; it's a string-parsing exercise otherwise.
• Reverse DNS lookups. The in-addr.arpa zone uses reversed octets: 1.1.168.192.in-addr.arpa for 192.168.1.1. Most DNS tools generate this for you, but if you're writing a script that issues PTR queries directly, you need the reversal.
• Hex in URLs and shorteners. Some legacy applications and obfuscators encode IPs as hex (http://0xC0A80101/) because browsers parse it. Useful to recognize when looking at suspicious URLs.
• Embedded systems and config files. Some routers, switches, and old PHP applications accept integer or octal forms in their configuration. Knowing the conversion saves time.

Special address ranges

A few ranges have specific meanings independent of the conversion:

• Private: 10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16 — not routable on the public internet.
• Loopback: 127.0.0.0/8 — connections to these never leave the host.
• Link-local: 169.254.0.0/16 — auto-assigned when DHCP fails. Almost never useful.
• Multicast: 224.0.0.0/4 — group communication.
• CGNAT: 100.64.0.0/10 — used by ISPs for carrier-grade NAT (your mobile carrier probably gives you one of these).
• Broadcast: 255.255.255.255 — limited broadcast to the local subnet.
• "This network": 0.0.0.0/8 — placeholders, the unspecified address.

Common pitfalls

• The decimal form can confuse browsers and humans. http://3232235777/ works in some browsers (they convert to 192.168.1.1 internally). Phishing campaigns sometimes use this to obscure where a link goes.
• Octal interpretation. The standards say a leading zero in an octet implies octal (0177 = 127), but browsers and OSes disagree. Linux's inet_aton parses 0177 as 127; Windows's InetPtonA rejects it. Avoid octal in production code.
• Sign-bit traps. 32-bit integers in some languages (signed C int, Java int) become negative for addresses ≥ 128.0.0.0. Cast to unsigned before display or use a 64-bit type to dodge this entirely.
• Endianness in binary protocols. Network byte order is big-endian. When packing/unpacking IPs in binary protocols, ensure you're not relying on host byte order, which is little-endian on x86.