CIDR Calculator

Subnet, prefix and supernet maths for IPv4 and IPv6 — computed in your browser

Every prefix length is listed with the block that would contain this address.

Parsed as192.168.1.55IPv4Private (RFC 1918)
PrefixBlockRangeAddresses
/00.0.0.0/00.0.0.0 255.255.255.2554,294,967,296
/1128.0.0.0/1128.0.0.0 255.255.255.2552,147,483,648
/2192.0.0.0/2192.0.0.0 255.255.255.2551,073,741,824
/3192.0.0.0/3192.0.0.0 223.255.255.255536,870,912
/4192.0.0.0/4192.0.0.0 207.255.255.255268,435,456
/5192.0.0.0/5192.0.0.0 199.255.255.255134,217,728
/6192.0.0.0/6192.0.0.0 195.255.255.25567,108,864
/7192.0.0.0/7192.0.0.0 193.255.255.25533,554,432
/8192.0.0.0/8192.0.0.0 192.255.255.25516,777,216
/9192.128.0.0/9192.128.0.0 192.255.255.2558,388,608
/10192.128.0.0/10192.128.0.0 192.191.255.2554,194,304
/11192.160.0.0/11192.160.0.0 192.191.255.2552,097,152
/12192.160.0.0/12192.160.0.0 192.175.255.2551,048,576
/13192.168.0.0/13192.168.0.0 192.175.255.255524,288
/14192.168.0.0/14192.168.0.0 192.171.255.255262,144
/15192.168.0.0/15192.168.0.0 192.169.255.255131,072
/16192.168.0.0/16192.168.0.0 192.168.255.25565,536
/17192.168.0.0/17192.168.0.0 192.168.127.25532,768
/18192.168.0.0/18192.168.0.0 192.168.63.25516,384
/19192.168.0.0/19192.168.0.0 192.168.31.2558,192
/20192.168.0.0/20192.168.0.0 192.168.15.2554,096
/21192.168.0.0/21192.168.0.0 192.168.7.2552,048
/22192.168.0.0/22192.168.0.0 192.168.3.2551,024
/23192.168.0.0/23192.168.0.0 192.168.1.255512
/24192.168.1.0/24192.168.1.0 192.168.1.255256
/25192.168.1.0/25192.168.1.0 192.168.1.127128
/26192.168.1.0/26192.168.1.0 192.168.1.6364
/27192.168.1.32/27192.168.1.32 192.168.1.6332
/28192.168.1.48/28192.168.1.48 192.168.1.6316
/29192.168.1.48/29192.168.1.48 192.168.1.558
/30192.168.1.52/30192.168.1.52 192.168.1.554
/31192.168.1.54/31192.168.1.54 192.168.1.552
/32192.168.1.55/32192.168.1.55 192.168.1.551

How to use this

  1. IP lookup — paste one address to see which block it falls into at every prefix length. Useful when someone quotes a network in one prefix and you need another.
  2. Subnet details — paste a CIDR block for the network address, mask, broadcast, usable host range, and exact address counts.
  3. Supernet — paste a list of addresses to get the single smallest block that covers them all, which is the prefix you would advertise or allow-list.

Everything is computed in your browser with arbitrary-precision integers, so IPv6 counts stay exact and nothing you type leaves the tab.

What CIDR notation actually means

Classless Inter-Domain Routing arrived in 1993 to replace the old Class A, B and C split, which handed out addresses in three fixed sizes: 16.7 million, 65,536, or 256. An organisation that needed 400 addresses had to take a Class B and waste 65,000 of them. CIDR threw the classes away and made the boundary between "network part" and "host part" a number you choose.

That number is the prefix length — the digits after the slash. It says how many leading bits of the address identify the network; everything left over identifies a host inside it. 10.0.0.0/8 means the first 8 bits are fixed and the remaining 24 bits are yours, which is 16,777,216 addresses. 10.0.0.0/24 fixes 24 bits and leaves 8, so 256 addresses. Every step you add to the prefix halves the block; every step you remove doubles it. That single rule is most of subnetting.

Reading a subnet mask

A netmask is the same information written as an address: ones for the network bits, zeros for the host bits. A /24 is 24 ones followed by 8 zeros, which spells out as 255.255.255.0. A /20 borrows four bits from the third octet and becomes 255.255.240.0. The wildcard mask is the bitwise inverse — the form access control lists in older router configs expect.

Two addresses in an IPv4 block are not assignable to hosts. The first is the network address itself, used to name the block in routing tables; the last is the broadcast address, which reaches every host on the segment at once. That is where the familiar "total minus two" comes from: a /24 holds 256 addresses but only 254 usable hosts. Getting this wrong by one is the classic cause of a DHCP pool that quietly refuses its final lease.

Why /31 and /32 are special

The minus-two rule breaks at the small end, and this is where our team sees most calculators disagree. RFC 3021 defines /31 for point-to-point links: with exactly two addresses there is nobody to broadcast to that a unicast would not already reach, so both addresses are assignable and no broadcast address is reserved. Router-to-router links use this constantly, because the older habit of spending a /30 on every link wastes half the block.

A /32 is a host route: one address, no network or broadcast address to set aside. Load balancer VIPs, loopback interfaces on routers, and firewall rules that name a single machine are all /32 entries. If a tool reports a /31 as having zero usable hosts, it is applying a rule from before 2000.

IPv6 subnetting is a different exercise

IPv6 keeps the prefix idea and changes almost everything around it. There is no broadcast address at all. Anything IPv4 did with broadcast is handled by multicast groups such as ff02::1 (all nodes on the link) and by the subnet-router anycast address, so there is nothing to subtract and the usable count equals the total count.

The standard subnet size is /64, and not by convention alone: stateless address autoconfiguration expects 64 host bits so a device can derive its own interface identifier. Going narrower than a /64 breaks SLAAC, which is why /64 is handed out even for a link carrying two machines. Providers typically delegate a /56 or /48 to a site, leaving 256 or 65,536 subnets to plan with.

Host-count arithmetic also stops being the point. A single /64 contains 18,446,744,073,709,551,616 addresses — more than the entire IPv4 internet, squared and then some. The interesting question moves from "will the hosts fit" to "does this prefix stay aggregatable and does it overlap anything else". Writing the address canonically matters more too: RFC 5952 asks for lowercase hex, no leading zeros in a group, and the longest run of zero groups collapsed to a single ::, with the leftmost run winning a tie. So 2001:0db8:0000:0000:0000:0000:0000:0001 is written 2001:db8::1. Diffing configs is far easier when everyone writes the same address the same way.

Supernetting and route aggregation

Supernetting runs the maths backwards: instead of splitting a block, it finds the one prefix that covers several. Four adjacent /24 networks starting at 10.0.0.0 summarise into a single 10.0.0.0/22. One route replaces four, and that compression is what keeps the global routing table finite — without aggregation every provider would advertise every small allocation separately.

The mechanic is simple once you see it: take the lowest and highest addresses, exclusive-or them, and count the bits above the highest difference. Those are the bits the addresses share, and that count is the prefix. The catch is that summarising can pull in addresses nobody intended to include, so aggregate for routing and be precise for firewalls.

Where this comes up in practice

  • Cloud network plans. A VPC gets one block and every subnet carves out of it. Sizing subnets so they neither overlap nor strand address space is the whole job, and cloud providers reserve a few addresses per subnet on top of network and broadcast — so the usable count is smaller than the arithmetic suggests.
  • Kubernetes pod CIDRs. Clusters hand each node a slice of the pod range, commonly a /24. A /16 pod CIDR sliced into /24s caps the cluster at 256 nodes no matter how much compute is available, and enlarging it later usually means rebuilding. If you are still mapping out how the pieces fit together, our notes on why teams reach for Kubernetes after Docker cover the surrounding model, and the kubeconfig manager helps once several clusters exist.
  • Peering and VPNs. Two networks can only be joined if their blocks do not overlap. A site that took 10.0.0.0/8 because it was easy to type will collide with almost every partner it later tries to peer with.
  • Firewall and allow-list rules. Converting "these machines" into a prefix, then checking the prefix has not swept in extra addresses, is exactly what the supernet mode is for.
  • The CGNAT surprise. 100.64.0.0/10 is reserved for carrier-grade NAT by RFC 6598. It looks public, it is not private under RFC 1918, and it turns up on mobile connections and inside some managed platforms. Anyone who assumes a non-1918 address is internet-routable gets caught by it eventually, usually while debugging why a callback never arrives.

Addressing sits next to name resolution in most incidents, so how DNS works is worth a read alongside this page. For unit-scale conversions there is the unit converter, and for decoding values pulled out of a config there is the Base64 encoder and decoder.

Related Articles