IP to Binary Converter

Dotted decimal is a display convention

An IPv4 address is a single 32-bit unsigned integer. The four dotted numbers are just those 32 bits split into bytes and written in decimal for humans. 192.168.1.1 is 3232235777 as an integer and C0A80101 in hex, and all three are literally the same value. Databases often store the integer form because it sorts and range-queries correctly, which dotted strings do not: as text, 10.0.0.9 sorts after 10.0.0.10.

Subnet masks only make sense in binary

A /26 looks arbitrary in decimal, where the mask is 255.255.255.192. In binary it is twenty-six ones followed by six zeros, and the rule becomes obvious: the ones mark the network part, the zeros mark the host part, and the boundary is always a clean split. The 192 in that mask is 11000000, the first two bits of the last byte, which is why /26 subnets step in increments of 64.

Why the increments are what they are

Every prefix length has a block size of 2 to the power of the remaining host bits. A /24 leaves 8 host bits, so blocks step by 256. A /26 leaves 6, so they step by 64: .0, .64, .128, .192. A /28 leaves 4 and steps by 16. Once you see this in binary you can do subnetting mentally, and the tables people memorise become unnecessary.

Hexadecimal shows up in packet captures

Raw packet dumps and low-level tooling display addresses in hex, where each byte is exactly two characters. Recognising C0A8 as the start of a 192.168 address is a genuinely useful reflex when reading a capture, since it appears identically wherever the address occurs in the frame.

The integer form and its traps

Converting to a 32-bit integer is common in application code, but signed 32-bit types overflow for any address above 127.255.255.255, turning 192.168.1.1 into a negative number. Use an unsigned type or a 64-bit one. This is the source of a persistent class of bug where everything works in testing on a 10.x network and breaks on public addresses.