¿Por qué a veces obtengo muchos bloques CIDR pequeños en vez de uno?

Esto pasa cuando el rango no se alinea a un límite limpio de potencia de 2 — el algoritmo tiene que dividirlo en la menor cantidad posible de bloques alineados, que puede seguir siendo varios para rangos impares.

¿Puedo usar esto directamente en reglas de firewall?

Sí, la mayoría de firewalls y grupos de seguridad en la nube (AWS, Cloudflare, etc.) aceptan notación CIDR directamente, así que puede pegar los bloques generados tal cual.

IPv4 Range Expander

Start IP

End IP

How to use this IPv4 range expander

Type a start and end IP address defining your range.
The tool calculates the minimal set of CIDR blocks that exactly cover that range.
Use the result in firewall rules or routing configuration.

Why does a range need multiple CIDR blocks?

CIDR blocks must start on an address boundary aligned to their size (a /24 must start at a multiple of 256, for example). Arbitrary ranges rarely align perfectly, so they're split into the largest possible aligned blocks that fit.

Why do I sometimes get many small CIDR blocks instead of one?

This happens when the range doesn't align to a clean power-of-2 boundary — the algorithm has to break it into the fewest aligned blocks possible, which can still be several for odd ranges.

Can I use this for firewall rules directly?

Yes, most firewalls and cloud security groups (AWS, Cloudflare, etc.) accept CIDR notation directly, so you can paste the generated blocks as-is.

The actual algorithm behind range-to-CIDR expansion

Converting an arbitrary IP range into the minimal set of CIDR blocks isn't guesswork — it follows a specific greedy algorithm. Starting from the range's first address, the algorithm finds the largest possible CIDR block that both starts exactly at that address and doesn't extend past the range's end address, adds that block to the result, then repeats the same process starting from the address immediately after that block. This greedy, largest-block-first approach is provably optimal — it always produces the fewest possible CIDR blocks needed to exactly cover the given range, which is why this tool's output is the minimal representation, not just any valid one.

Why alignment, not just size, determines block boundaries

A common misconception is that a CIDR block just needs to be the right size — a /24 has 256 addresses, so surely any 256 consecutive addresses would work. In reality, a CIDR block must also start at an address boundary aligned to its size: a /24 can only start at an address where the last 8 bits are all zero, meaning it must begin at a multiple of 256, not at an arbitrary starting point. This alignment requirement comes directly from the binary math — a subnet is defined by fixing a certain number of leading bits, and the only valid starting addresses for a given prefix length are ones where all the trailing (host) bits are zero. This is exactly why an arbitrary range rarely divides into one clean block and often requires several progressively smaller ones to cover the parts that don't align.

A real-world use case: converting published IP ranges into firewall-ready CIDR

This kind of range-to-CIDR conversion comes up constantly in practice: cloud providers, ISPs, and security vendors frequently publish IP ranges to allow or block as a simple start-end pair (particularly in threat intelligence feeds and vendor documentation), but most firewalls, cloud security groups, and routing configurations only accept CIDR notation rather than arbitrary ranges. Converting a published range into its minimal CIDR set is what makes that data usable in a real firewall rule or security group configuration, and doing it correctly (rather than just picking one convenient but inaccurate CIDR block) matters for both security completeness and avoiding unintentionally blocking or allowing addresses outside the intended range.

Why the same size range can need a wildly different number of blocks

The number of CIDR blocks needed to cover a range depends heavily on where that range starts and ends, not just how many addresses it spans. A range of exactly 256 addresses that happens to start at a /24-aligned boundary needs exactly one CIDR block. The same 256-address span starting at an unaligned address (say, the 100th address within some larger block) might need to be split into a dozen or more progressively sized blocks to cover it exactly, since the algorithm has to work outward from that misaligned starting point using the largest valid block at each step. This is why two ranges of identical size can produce very different-looking, and very different-sized, CIDR block lists.

Limitations of this tool

This tool computes the mathematically minimal set of IPv4 CIDR blocks that exactly cover a given start-to-end address range — it doesn't validate that the range makes practical sense for your specific network, doesn't check the resulting blocks against other CIDR ranges you might already have configured elsewhere (to catch unintended overlaps), and only handles IPv4 addressing, not IPv6 ranges. It also optimizes purely for the fewest number of blocks, not for readability or round numbers, so an odd input range can still produce a list of oddly-sized blocks that are mathematically correct but not necessarily the cleanest-looking output.