Enter an IP address with CIDR prefix (e.g. 192.168.1.0/24) or IP + subnet mask. Get network address, broadcast, usable range, total hosts, binary breakdown, and subnet splitting. 100% client-side.
CIDR (Classless Inter-Domain Routing) notation compactly specifies an IP address range using a suffix: 192.168.1.0/24. The number after the / is the prefix length — the count of bits in the network portion of the address.
2^(32-prefix) - 2./24 = 255.255.255.0.Common private ranges: 10.0.0.0/8 (16.7M hosts), 172.16.0.0/12 (1M hosts), 192.168.0.0/16 (65K hosts). All calculations happen in your browser.
Every subnetting tutorial teaches 2^(32-prefix) - 2. The formula assumes a classic broadcast domain, and it stops being true at both ends of the prefix range — and inside a cloud VPC.
/31 — two hosts, nothing wasted. RFC 3021 defines /31 for point-to-point links. A /31 contains exactly two addresses and has no network or broadcast address, because there is no third party to broadcast to. Two routers on a serial link simply use both. The textbook formula says a /31 has zero usable hosts.
/32 — one host, by definition. A /32 is a single address, and that is how host routes are written everywhere: 203.0.113.7/32 in a firewall rule or a route table means that one machine, not a range. The formula returns a negative number here.
Cloud subnets reserve more than two. AWS removes five addresses from every subnet: the network address, the VPC router at base+1, the DNS resolver at base+2, one held for future use at base+3, and the broadcast address at the top. A /24 in a VPC therefore yields 251 assignable addresses, not 254, and a /28 yields 11, not 14. Azure reserves five as well; GCP reserves four. Size subnets from the textbook number and your smallest subnets will come up short by exactly the amount you did not account for.
Take 10.0.0.0/22 — 1,024 addresses, of which 1,022 are usable on paper and 1,019 are assignable in AWS — and suppose you need four subnets of comparable size.
A /22 leaves 10 host bits. Moving to a /24 borrows two of them for the network, which gives 2^2 = 4 subnets of 2^8 - 2 = 254 usable addresses each:
10.0.0.0/24 → 10.0.0.1 – 10.0.0.25410.0.1.0/24 → 10.0.1.1 – 10.0.1.25410.0.2.0/24 → 10.0.2.1 – 10.0.2.25410.0.3.0/24 → 10.0.3.1 – 10.0.3.254Notice what happened to the third octet: it went 0, 1, 2, 3. That is not a coincidence — each borrowed bit doubles the subnet count and halves the size, so the boundary always lands on a power of two. That is the whole of VLSM. Decide how many subnets you need, round up to the next power of two, borrow that many bits.
The same arithmetic in reverse explains why a /23 is awkward to split evenly: it is already two /24s, so you get two subnets or four /25s, never three.
1. Budgeting the address count instead of the host range. 192.168.1.0/24 holds 256 addresses but 254 hosts. Teams that plan for 256 devices per /24 run out two addresses early, every time. The near-miss version is worse: writing 192.168.1.1/24 as though .1 were the network. The network is 192.168.1.0; .1 is simply the first host.
2. Overlapping ranges nobody compared. 10.0.0.0/16 and 10.0.128.0/17 look like different networks until you see that the second sits entirely inside the first. This is the usual cause of a VPN or peering link that sends half its traffic to the wrong side. Check every pair of CIDRs before you connect two networks, not just the pairs you suspect.
3. Picking a prefix with no room to grow. A VPC created at /24 is one subnet with nothing left to divide. AWS's own guidance is to start a VPC at /16 and carve /24s out of it. Changing that decision later means re-creating the VPC and re-addressing everything inside it, so it is worth ten seconds now.