CIDR Calculator
CIDR to IP Range, and IP Range Back to CIDR

What Is a CIDR Calculator and What Does It Actually Return?

A CIDR calculator takes classless inter-domain routing notation — an address followed by a slash and a prefix length, like 10.0.0.0/24 — and expands it into everything a router or firewall needs to know about that block. That means the network address, the broadcast address, the subnet mask, the wildcard mask, the total block size, and the range of addresses you can hand to real machines.

The word doing the work is classless. Before 1993 an address block's size was fixed by its first few bits, so you took 16 million addresses or 254 and nothing in between. CIDR untied size from address, which is why a CIDR block calculator has to be told the prefix explicitly — the address alone no longer implies it. RFC 4632, published by the IETF in August 2006 and still the governing CIDR specification in 2026, is where those rules are set out.

Both Directions, Not Just One

Almost every CIDR notation calculator online runs one way only — a CIDR expander that takes a block in and gives a range out, and nothing more. In practice half the work goes the other way. Someone sends you an allowlist as a start and end address. A vendor gives you a netmask instead of a prefix. You have a single host IP and need it in slash form for a security group. This calculator accepts all of those:

• CIDR block — 10.0.0.0/24 expands into its full IP range
• IP range — 10.0.0.5 - 10.0.0.20 collapses into the CIDR blocks that cover it
• Address and mask — 10.0.0.0 255.255.255.0 converts the subnet mask to a prefix
• Bare address — 203.0.113.45 returns its /32 form for firewall rules

How Do You Convert an IP Range Back to CIDR?

To convert an IP range to CIDR — sometimes called CIDR translation or finding the CIDR range for a set of addresses — you repeatedly take the largest legal block that starts at your current position and does not overshoot the end, then move forward and repeat. The result is usually more than one block, and that surprises people the first time they see it. A CIDR block must cover a power-of-two count of addresses and begin on a matching boundary, so arbitrary ranges rarely collapse into one.

A Range That Does Not Fit Neatly

Take 10.0.0.5 to 10.0.0.20. That is 16 addresses, which is exactly a /28 — so it looks like it should be one block. It is not, because it starts at .5 instead of a boundary:

I hit this constantly with partner allowlists. Someone sends "our egress is .5 through .20" and the security group needs five entries rather than the one they assumed. If you control the range, moving the boundaries out by a few addresses collapses five rules into one — cheaper to read, cheaper to audit, and under most cloud rule-count limits it genuinely matters.

Converting a Subnet Mask to CIDR

The mask conversion is simpler: count the leading 1 bits. 255.255.255.0 is twenty-four 1 bits, so /24. Going the other way — CIDR to subnet mask — you write that many 1 bits and pad the rest with zeros. The nine values below are the only ones a legal mask octet can hold, because a mask must be an unbroken run of 1s followed by 0s — which is why 255.0.255.0 is a valid address but an invalid mask, and this calculator rejects it.

If you want to watch the bits flip rather than trust the table, push the address through our IP to binary converter and read the mask boundary directly.

How Do You Check Whether Two CIDR Blocks Overlap?

Two CIDR blocks overlap when either one contains the other's network address. There is no separate overlap checker needed: expand both blocks here, then check whether their first-to-last IP range intervals touch at any point. Identical blocks are the obvious case. The one that catches people is a wide block quietly swallowing a narrow one — 10.0.0.0/16 and 10.0.5.0/24 look unrelated at a glance, but the second sits entirely inside the first.

Where Overlap Actually Breaks Things

Inside a single routing table, overlap is not fatal. Routers resolve it with longest prefix match — the most specific route wins, so 10.0.5.0/24 beats 10.0.0.0/16 for traffic to 10.0.5.7. That is by design and used deliberately all the time.

Cloud networking is far less forgiving. As of August 2026, VPC peering, transit gateway attachments and site-to-site VPN tunnels on all three major providers still refuse outright when the two sides overlap, with no longest-prefix fallback:

An Allocation Convention That Prevents It

The cheapest fix is a naming convention agreed before anyone opens a console, because you cannot resize a VPC block later without rebuilding it:

1. Give each environment its own /16 — production 10.0.0.0/16, staging 10.1.0.0/16, development 10.2.0.0/16
2. Give each region its own second octet if you run multi-region, so 10.10.0.0/16 and 10.20.0.0/16 never collide
3. Reserve one block for transit, VPN and inspection so shared services always have somewhere to live
4. Leave a full empty block between tiers, so widening the web tier later does not force renumbering the app tier
5. Avoid 172.17.0.0/16 entirely — Docker claims it by default, and containers lose connectivity when a VPC uses it too

Understanding which ranges are safe to allocate from starts with knowing the difference between routable and non-routable space, which our guide to public and private IP addressing covers in full.

Wildcard Masks: CIDR Translated for Cisco ACLs

A wildcard mask is the bitwise inverse of a subnet mask: 0 means "this bit must match" and 1 means "ignore this bit". A /24 has subnet mask 255.255.255.0 and wildcard mask 0.0.0.255. You need it the moment you touch Cisco IOS, because access control lists and OSPF network statements take the wildcard form rather than the mask, and getting the two the wrong way round is the single most common lab mistake there is.

The mistake I see most often is pasting 255.255.255.0 where 0.0.0.255 belongs. The command is accepted, the ACL loads, and it then matches an address set that has nothing to do with your intent. There is no warning, because both values are syntactically valid. The wildcard mask returned by the calculator above is ready to paste straight into a config, which removes the flip step entirely.

Wildcard masks are not a routing concept in themselves — they are a matching syntax layered on top of the same bit boundaries CIDR uses. If the underlying network-versus-host split is what feels shaky, our explainer on how subnet masks divide an address is the place to start before returning here.

CIDR in IPv6: Same Notation, Very Different Scale

CIDR notation works identically in IPv6 — an address, a slash, a prefix length — but the numbers stop being intuitive. IPv4 gives you 32 bits and roughly 4.3 billion addresses in total. IPv6 gives you 128 bits, and a single /64 holds more addresses than the entire IPv4 internet squared.

Two habits from IPv4 have to be unlearned. There is no broadcast address in IPv6, so the "subtract 2" arithmetic that governs every IPv4 block simply does not apply — a /64 gives you all of its addresses with nothing reserved off the top. And subnetting below /64 breaks stateless address autoconfiguration, so even when you only need six hosts, you still assign a /64.

To be clear about this tool's scope: the calculator above is IPv4 only, prefixes /0 through /32. IPv6 address counts exceed what 32-bit integer maths can represent, and returning a rounded figure would be worse than returning nothing. For IPv6 address formatting and compression, use our IPv6 address expansion tool, and for the addressing model itself our beginner's guide to IPv6 addresses covers the ground properly.