Subnet calculator

A subnet mask is a run of ones followed by a run of zeros, and everything else follows from that. The ones mark the network part of the address and the zeros the host part, so ANDing an address with its mask gives the network address, and ORing it with the inverted mask gives the broadcast. That is the whole calculation; the rest is presentation.

The usable count is total minus two, because the all-zeros host is the network itself and the all-ones host is the broadcast. Two prefixes break that rule and both are common in real configurations. A /31 has no broadcast at all: RFC 3021 defines it as a point-to-point link with two usable addresses, which is why router-to-router links are configured that way and why a calculator reporting "0 usable hosts" for a /31 is wrong. A /32 is a single host; a host route rather than a network.

The prefix reads backwards the first hundred times: a longer prefix is a smaller network, because it counts network bits and leaves fewer for hosts. Each bit added halves the block, which is also why every count is a power of two and why you cannot have a network of exactly 300 addresses: you take a /23 and its 512, and use 300. CIDR replaced the fixed class boundaries in 1993 for precisely that reason: under classes, an organisation needing 300 addresses had to take a class B and waste 65,000 of them. The class row is still shown because people still say "a class C" when they mean a /24, and because the class sets the default mask on equipment old enough to care. It has had no effect on routing for thirty years.

A prefix must also be aligned to its own size. 10.0.1.0/23 is not a valid network, because a /23 has to start on an even third octet; equipment will usually reject it, and the containing network 10.0.0.0/23 is shown here instead. The same alignment rule is what makes a start-and-end range expensive to express in CIDR: 192.168.1.1 to 192.168.1.6 is six addresses and needs four blocks (192.168.1.1/32, 192.168.1.2/31, 192.168.1.4/31 and 192.168.1.6/32), because 1 is odd and can only start a /32. Take the largest aligned block that fits at the current address, move past it, repeat: that greedy walk is provably the smallest set, and the sizes sum to exactly the number of addresses between the two ends with nothing extra. The temptation is to round the whole thing up to one containing block instead, and in a firewall rule that grants access to every address the block covers beyond the range you meant. Ranges that begin and end on power-of-two boundaries collapse to a single block, which is a good argument for choosing them when you get to.

Only nine values can appear in a mask octet: 0, 128, 192, 224, 240, 248, 252, 254 and 255, one for each number of leading ones. Anything else is not a contiguous mask: 255.0.255.0 is the classic, and it is invalid because the network/host split has to be a single boundary rather than a scattered set of bits. Non-contiguous masks were briefly legal in the early internet and were removed because they make the longest-prefix match every router depends on impossible to do efficiently. The quickest check is to invert the mask and add one; a valid mask always gives a power of two.

That short list also turns the reverse direction, a dotted-decimal mask back to a prefix, into something you read off rather than compute, since each octet value stands for a fixed number of ones: 128 is 1, 192 is 2, 224 is 3, 240 is 4, 248 is 5, 252 is 6, 254 is 7, 255 is 8, and 0 is none. Add them up and you have the prefix. 255.255.240.0 is 8 + 8 + 4, so /20; 255.255.255.192 is 8 + 8 + 8 + 2, so /26. The two notations are the same boundary written twice, and equipment is split on which it wants: Linux and Cisco interface configuration take the mask, routing tables and firewall rules almost always take the prefix. The wildcard mask, which is the subnet mask inverted, is worth knowing separately, because Cisco access lists and OSPF take it instead of a subnet mask, and writing 255.255.255.0 where 0.0.0.255 belongs silently matches an entirely different set of addresses.

The scope row is the practically useful one. RFC 1918 reserves 10.0.0.0/8, 172.16.0.0/12 and 192.168.0.0/16 for private use, and the middle block is where the mistakes live: it covers 172.16 through 172.31, not all of 172. Three more ranges answer questions people actually have. 169.254.0.0/16 is link-local, which a machine assigns itself when DHCP fails. Seeing one is a diagnosis rather than a configuration. 100.64.0.0/10 is carrier-grade NAT, which is why port forwarding does nothing on some connections and why a "public IP" you looked up may be unreachable. And 127.0.0.0/8 is all loopback, not just 127.0.0.1. Worth stating plainly, because the confusion is common: private is a routing property, not a security boundary. Anything on the same network reaches a private address freely.

The binary rows are there because that is how subnetting is actually taught, and for good reason: the mask is a boundary drawn through 32 bits, and it only looks arbitrary in decimal. 255.255.240.0 is unremarkable as a number and completely clear as twenty ones followed by twelve zeros. It is also the quickest way to check whether two addresses can talk without a router: mask both and compare the network halves. Underneath the dots the address is one 32-bit number: 192.168.1.1 is 3232235777, which is why databases holding IP data usually store the integer, since a subnet is then a contiguous span and "is this address in this network" becomes a comparison rather than string parsing. Sorting is the other reason: as text, "10.0.0.1" sorts before "9.0.0.1", and as an integer it does not.

Packing and unpacking that integer is two lines of arithmetic in either direction. To pack, a×16777216 + b×65536 + c×256 + d, which is what the binary row shows written out in bits. To unpack, shift right by 24, 16, 8 and 0 and mask each result with 255. The whole space is 0 to 4,294,967,295, or 0.0.0.0 to 255.255.255.255, and both ends are valid integers that are not hosts you can talk to. The integer, binary and hex mode does that round trip in both directions: one field takes whichever notation you have, says which one it decided it was, and prints the other three beside the in-addr.arpa name. Three traps come with the trip, and the mode is arranged around all three. A value stored in a signed 32-bit column cannot hold anything from 128.0.0.0 up and comes back negative; paste the negative straight in and it is recovered by adding 4,294,967,296, with a line saying that is what happened, because the column still wants to be unsigned or 64-bit. Byte order matters absolutely: reverse it and 192.168.1.1 becomes the perfectly valid 1.1.168.192, which is the classic endianness bug and never announces itself, which is why nothing here reorders bytes for you. And a leading zero is not decoration: 010.0.0.1 is 10.0.0.1 by the arithmetic above and 8.0.0.1 to the C library’s inet_aton, and two parsers disagreeing about that has been the root of real access-control bypasses. Rather than quietly become one of those two parsers, the panel refuses the string and says why. Reading four notations from one field creates one more ambiguity, settled the same way: digits alone are decimal, so 10101010 is 10,101,010 and not the eight hexadecimal digits it also happens to be, and hexadecimal with no letter in it has to carry its 0x. In hexadecimal the same address is padded to eight digits, two per octet, so 192.168.1.1 is C0A80101. MySQL exposes the conversion directly as INET_ATON and INET_NTOA; PostgreSQL has a native inet type that does the range arithmetic itself, so the integer round trip is rarely worth doing there.

Every row above is 32-bit arithmetic, so IPv6 is a different shape rather than a wider version of the same thing: 128 bits, written as eight groups of four hexadecimal digits, and no integer column will hold one. The written form has two rules and they cause most of the confusion. Leading zeros inside a group are dropped, so 2001:0db8:0000:0000:0000:0000:0000:0001 loses them; then the longest run of all-zero groups collapses to a single ::, giving 2001:db8::1. That double colon may appear only once, because two would leave no way to know how many groups each stood for, and when two runs are equally long the leftmost is the one that goes. A run of a single group is left alone, because :0: is already as short as ::. Expanding is the same rules backwards: count the groups you can see, and the :: stands for however many all-zero groups are missing from eight. The prefix works exactly as it does here, as a count of leading bits, but the sizes are fixed by convention rather than by arithmetic: a subnet is a /64 because stateless autoconfiguration needs 64 host bits, and an ISP hands out a /56 or /48 to be cut into /64s. There is no broadcast address at all, since multicast in ff00::/8 replaced it, and every interface carries a link-local fe80::/10 address whether anything was configured or not, which is the IPv6 counterpart of seeing a 169.254 address, except that here it is normal.

One implementation note that explains a lot of broken calculators. JavaScript’s bitwise operators return a signed 32-bit integer, so any address from 128.0.0.0 up comes back negative and prints as nonsense. Every value here is pushed back through an unsigned shift. If a subnet calculator gives you sensible answers for 10.x and garbage for 200.x, that is the bug, and the same signed-column mistake is why an address stored in a database sometimes comes back negative, recoverable by adding 4,294,967,296.