CIDR Range Merger — summarise many blocks into few

A CIDR range merger takes a list of IPv4 blocks — the kind that accumulates in a firewall allowlist, a route table, or a cloud security group over several years — and reduces it to the shortest set of prefixes that covers exactly the same addresses. Not approximately the same. Exactly. Four contiguous /26 blocks become one /24. Two /25 halves become their parent /24. Blocks that are close but not adjacent stay separate, because merging them would silently authorise addresses nobody asked to authorise.

Arb Digital's team maintains infrastructure for client web applications, and rule lists are one of the places where entropy wins quietly. A security group that started with three entries ends up with sixty, most of them fragments of the same ranges added at different times by different people. This page collapses them in one pass, entirely in your browser, with no data leaving the tab.

What This CIDR Range Merger Does

Paste any number of IPv4 CIDR blocks. Each is converted into a numeric start and end address, the whole set is sorted, and overlapping or touching ranges are joined. Every joined range is then decomposed back into the minimal list of valid CIDR prefixes that exactly covers it — which is the part most manual attempts get wrong, because a contiguous range does not always reduce to a single prefix.

The hero shows the summarisation itself: how many blocks went in and how many came out. The four supporting figures give you the count of blocks accepted after validation, the merged block count, the total number of addresses covered, and the largest single prefix in the result — the last of these being the one to sanity-check before you paste anything into a firewall, because a surprisingly short prefix means a surprisingly wide grant.

Output is available in four notations. CIDR is the default. Start–end ranges suit systems that take explicit bounds. Wildcard mask output is what Cisco IOS access lists expect, and it is simply the inverted subnet mask. Subnet mask output is what most static route commands and older firewall interfaces want.

How to Use It

1. Paste your blocks. One per line is clearest, but spaces, commas, and semicolons all work as separators, so a copied rule list usually pastes in without editing.
2. Include bare addresses if you have them. A single IPv4 address with no prefix is treated as a /32, which is how firewall rules for individual hosts are normally written.
3. Pick the output format your target system expects — CIDR, explicit range, wildcard mask, or subnet mask.
4. Click Merge Ranges. The counters update together and the summarised list appears in the output box.
5. Check the largest block figure before you deploy. If a list of /24s collapsed to something as wide as a /16, confirm that is genuinely what your inputs covered.

How the Merge Is Calculated

Each block is converted to a 32-bit integer. The network address is derived by masking the address with its prefix length, so 172.16.5.7/24 is normalised to 172.16.5.0/24 — the host bits are discarded, exactly as a router would discard them. The end address is the network address plus 2^{(32−prefix)} − 1.

The ranges are sorted by start address, then swept once. A range is merged into the previous one when its start is less than or equal to the previous end plus one — the "plus one" is what makes adjacency work, since 192.168.0.0/24 ends at 192.168.0.255 and 192.168.1.0/24 begins at the very next address. Merged ranges keep the larger of the two end addresses, so a small block fully contained inside a larger one simply disappears into it.

The final step converts each merged range back into prefixes. Starting at the range's first address, the algorithm finds the largest block that is both aligned to that address and does not extend past the range's end, emits it, advances, and repeats. Alignment is the constraint that makes this exact: a block of prefix length n must begin at an address divisible by 2⁽³²⁻ⁿ⁾. That definition of a prefix comes straight from the classless addressing architecture described in RFC 4632, the CIDR specification, and it is the reason some contiguous ranges need several prefixes to express.

The Alignment Trap: Why Adjacent Is Not Always Mergeable

This is the single most common misunderstanding, and it is worth a worked example. Take 10.0.0.0/32 and 10.0.0.1/32. They are adjacent, and they merge cleanly into 10.0.0.0/31, because a /31 must start on an even address and 10.0.0.0 is even. Now take 10.0.0.1/32 and 10.0.0.2/32. They are equally adjacent — but they cannot become a /31, because a /31 starting at 10.0.0.1 is not a legal prefix. The pair covers two addresses that straddle a boundary, so the correct output is both /32s, unchanged.

The same rule scales up. 192.168.1.0/24 and 192.168.2.0/24 are adjacent, but their combined range starts at 192.168.1.0, which is not a valid /23 boundary — a /23 must start on an even third octet. The tool returns both /24s, and it is right to. Any tool that returns 192.168.0.0/22 there has just added 192.168.0.0/24 and 192.168.3.0/24 to your rule without telling you. On an allowlist, that is 512 addresses you did not intend to trust.

Verified test cases behind the implementation include exactly these: 10.0.0.0/32 + 10.0.0.1/32 → 10.0.0.0/31; 10.0.0.1/32 + 10.0.0.2/32 → two /32s, unmerged; 10.0.0.0/25 + 10.0.0.128/25 → 10.0.0.0/24; 10.0.0.0/24 + 10.0.1.0/24 + 10.0.2.0/24 → 10.0.0.0/23 plus 10.0.2.0/24; and 0.0.0.0/1 + 128.0.0.0/1 → 0.0.0.0/0.

Why /31 and /32 Behave Differently From Everything Else

In classic subnetting, the first address of a block is the network address and the last is the broadcast address, so a /24 offers 254 usable hosts rather than 256. That arithmetic breaks down at the small end. A /31 has only two addresses, which under the old rules would leave zero usable hosts, making it useless — yet /31s are used constantly on point-to-point links, because RFC 3021 defines both addresses in a /31 as usable endpoints with no network or broadcast address at all. A /32 is a single host route: one address, no network or broadcast concept.

For merging purposes none of this matters, because merging works on the full address range, not on the usable-host subset. But it matters enormously when you read the "addresses covered" figure. That number counts every address in the range including network and broadcast addresses. If you need usable-host counts, network and broadcast addresses, or a full breakdown of one specific block, use our IP subnet calculator — that tool analyses a single subnet in depth, where this one summarises many subnets into few. The two are complements, not competitors.

Where Route Summarisation Actually Pays Off

Router memory is the classic reason. Every prefix in a routing table consumes forwarding hardware resources, and on smaller devices that table is a hard limit. Collapsing sixteen /24 advertisements into one /20 cuts sixteen entries to one on every device that receives the advertisement.

The reasons that matter more for a typical web business are different. Cloud providers impose hard caps on rules per security group and routes per route table, and hitting one of those caps mid-incident is a genuinely bad afternoon. Firewall rule evaluation is often linear, so a shorter list is a faster list on high-traffic paths. And shorter lists are auditable: a human reviewing eight prefixes will notice an anomaly that the same human reviewing eighty will not.

There is a real trade-off on the other side. Summarised routes are harder to change granularly. Removing one /24 from a merged /20 means splitting the /20 back apart, and the split is not always obvious under pressure. Keep the original unsummarised list in version control alongside the merged one so the expansion is always available.

Handling Overlaps, Duplicates, and Bad Input

Duplicate entries collapse automatically — a block listed twice contributes the same range twice and merges into itself. Nested blocks do the same: if a /28 sits inside a /24 you also listed, the /28 vanishes into the /24, which is usually the discovery that motivated running the tool in the first place, since a redundant nested rule is dead weight that still costs an evaluation.

Entries with host bits set are normalised to their network address rather than rejected, and the tool reports how many it corrected. This is deliberate: 10.1.2.3/24 is what somebody meant to write as 10.1.2.0/24, and every router in the path would interpret it that way. Lines that cannot be parsed as IPv4 at all — an octet above 255, a prefix length outside 0 to 32, an IPv6 address, a hostname — are skipped and counted, so the accepted-blocks figure never silently disagrees with what you pasted.

IPv6 is out of scope here. The merging logic is identical in principle but requires 128-bit arithmetic, which JavaScript numbers cannot represent exactly, so supporting it properly means a different implementation rather than a loosened one.

Common Mistakes to Avoid

• Assuming any two adjacent blocks combine — the merged range must also start on a legal prefix boundary, or the result is not a valid CIDR block.
• Widening a prefix to "tidy up" a list — rounding a /23 up to a /22 silently grants access to 512 addresses that were never on the list.
• Reading "addresses covered" as "usable hosts" — the figure includes network and broadcast addresses, which differ per block and are not subtracted here.
• Discarding the original list after summarising — you will eventually need to remove one small range, and expanding a merged prefix from memory is error-prone.
• Pasting merged output into a live firewall without checking the largest block — one mistyped prefix length in the input can collapse the whole list into something far too permissive.

Related Free Tools From Arb Digital

Analyse a single subnet's mask, host range, and broadcast address with the IP subnet calculator, convert prefix arithmetic between bases with the number base converter, generate DNS zone entries for the hosts behind those ranges with our DNS record generator, build server redirect rules with the htaccess redirect generator, or check a response code with the HTTP status code lookup. Browse the free online tools hub for the rest.

Frequently Asked Questions