CIDR to IP Range Converter

CIDR notation and address ranges describe the same thing two different ways, and different tools want different ones. A firewall rule takes 10.0.0.0/24; an allow-list export gives you 10.0.0.0 to 10.0.0.255; a cloud console asks for one and your ticket quotes the other. This converter goes both ways: paste a block like 10.0.0.0/24 and it returns the network address, broadcast, and first and last usable host; paste a start and end address and it returns the minimal list of CIDR blocks that exactly covers the range.

Both directions run entirely in your browser and write their inputs into the page URL, so a result is a link you can drop straight into a ticket, a runbook, or a review. Nothing is uploaded and nothing is stored.

Expanding a CIDR block into an address range

A CIDR block is a base address and a prefix length: the /N counts how many leading bits are fixed. Everything the block contains shares those N bits, and the remaining 32 − N bits count off the addresses inside it. So the block holds 2^(32 − N) addresses, running contiguously from the network address (all host bits 0) to the broadcast address (all host bits 1). 10.0.0.0/24 fixes the first 24 bits, leaves 8 host bits, and therefore spans 10.0.0.0 through 10.0.0.255: 256 addresses, of which 10.0.0.1 through 10.0.0.254 are the 254 usable hosts.

The network and broadcast addresses are the two ends of that run. On an ordinary subnet the network address (the .0 here) names the subnet itself and the broadcast address (the .255) reaches every host on it, so neither is assignable to an interface, which is why a /24 offers 256 total but 254 usable addresses. Drop one bit and the counts double: a /23 is 512 addresses and 510 usable; add one and they halve.

Two prefixes are special because they have no room for a separate network and broadcast address. A /32 is a single address: first, last, and the address itself are all the same, and it is how you write a host route or a single-IP firewall entry. A /31 is a two-address block with no broadcast: RFC 3021 defines it for point-to-point links, where both addresses are usable as the two ends of the link. The converter reports broadcast and usable-host figures accordingly, showing a dash where a /31 or /32 has no broadcast to report.

Collapsing an address range into CIDR blocks

Going the other way is where the arithmetic gets interesting, because an arbitrary range usually cannot be written as a single CIDR block. A CIDR block has to be aligned: a block of size 2^k must start at an address that is a multiple of 2^k. A range whose start is not aligned to its length (or whose length is not a power of two) simply does not fit any one prefix, so it has to be broken into several aligned blocks that tile it exactly.

Take 192.168.1.10 to 192.168.1.20, eleven addresses. Eleven is not a power of two, and .10 is not aligned to a large block, so the cover comes out as four pieces: 192.168.1.10/31 (the .10–.11 pair), then 192.168.1.12/30 (.12–.15), then 192.168.1.16/30 (.16–.19), then 192.168.1.20/32 (the lone .20). Together those four blocks contain exactly the eleven addresses from .10 to .20 and not one more.

The converter builds that list greedily: at each step it places the largest block that both starts at the current address (respecting alignment) and does not run past the end of the range, then advances to the next uncovered address and repeats. Taking the largest aligned block every time is provably the minimal cover: no shorter list of CIDR blocks can describe the same range. In practice the lists stay short: even the most awkward IPv4 range needs at most a few dozen blocks.

Where each form is needed

Which notation you need is dictated by whatever consumes it, and the two rarely agree. Converting between them is a routine step in day-to-day network and security work:

• Firewall rules and ACLs: most accept CIDR, so a human-quoted "everything from .10 to .20" has to be turned into the block list before it can be pasted in.
• Cloud security groups and VPC rules: AWS, Azure, and GCP all take CIDR for source and destination ranges, never a raw start–end pair.
• Route objects and IRR / RPKI records: prefixes are registered and filtered in CIDR, so an allocation described as a range has to be expressed as aligned blocks.
• Geo-IP feeds and allow / deny lists: these are frequently published as start–end ranges, and collapsing them to CIDR is what lets them load into routers and firewalls.