IP Range to CIDR

Convert an arbitrary start-to-end IPv4 range into the minimal set of CIDR blocks that covers it exactly - no more, no less.

Converter IP & Subnetting Runs in your browser
Try:

Result

Addresses in range
452
CIDR blocks needed
11
Range
192.168.1.5 - 192.168.2.200

Exact decomposition

PrefixFirstLastAddresses
192.168.1.5/32192.168.1.5192.168.1.51
192.168.1.6/31192.168.1.6192.168.1.72
192.168.1.8/29192.168.1.8192.168.1.158
192.168.1.16/28192.168.1.16192.168.1.3116
192.168.1.32/27192.168.1.32192.168.1.6332
192.168.1.64/26192.168.1.64192.168.1.12764
192.168.1.128/25192.168.1.128192.168.1.255128
192.168.2.0/25192.168.2.0192.168.2.127128
192.168.2.128/26192.168.2.128192.168.2.19164
192.168.2.192/29192.168.2.192192.168.2.1998
192.168.2.200/32192.168.2.200192.168.2.2001
Prefix list
192.168.1.5/32
192.168.1.6/31
192.168.1.8/29
192.168.1.16/28
192.168.1.32/27
192.168.1.64/26
192.168.1.128/25
192.168.2.0/25
192.168.2.128/26
192.168.2.192/29
192.168.2.200/32
Poorly aligned range
This range needs 11 prefixes because it does not start or end on a power-of-two boundary. If you control the allocation, shifting the boundaries to align on a /24 or /25 would collapse it dramatically.

About IP Range to CIDR

Firewalls, DHCP servers and allocation spreadsheets like ranges. Routers, prefix lists and route filters want CIDR. This converts an arbitrary range into the exact set of prefixes that covers it - never one address more.

Designing ranges that stay small

Prefix count is a property of the boundaries, not the size. A range starting at .100 and ending at .199 needs half a dozen prefixes; shifting it to .128 through .255 makes it a single /25 of the same 128 addresses. When you control the allocation — DHCP pools, NAT pools, customer assignments — choose power-of-two boundaries and every downstream prefix list, route filter and firewall object stays short and reviewable.

Why the count varies so much

A range that starts and ends on power-of-two boundaries collapses into a single prefix. One that starts at .5 and ends at .200 needs a staircase of blocks: each step takes the largest prefix that both aligns with the current position and fits inside the remaining range. Ranges arranged by humans on decimal boundaries (100-199) are almost always the expensive kind.

Common use cases

  • Converting a legacy firewall range object into prefix-list entries.
  • Turning a DHCP scope into the CIDR notation a route filter needs.
  • Checking how much prefix churn a proposed allocation boundary will cause.

Edge cases and gotchas

  • The output covers the range exactly. If you want a single shorter summary that may over-cover, use the CIDR Aggregator with strict mode off.
  • Ranges spanning classful boundaries are handled, but the block count grows quickly.

Frequently asked questions

Which is safer for a firewall rule: a range or these prefixes?
They are equivalent here because the decomposition is exact — it covers the range and nothing more. Only summarising with a shorter prefix, which over-covers, changes what is permitted.
Why does 10.0.0.100 - 10.0.0.199 need seven prefixes?
Neither boundary aligns to a power of two. The decomposition is /30, /28, /26, /27 style staircase. Using 10.0.0.128 - 10.0.0.255 instead would be a single /25.