CIDR Overlap Checker
and What Your List Reduces To

Why Can't Two CIDR Blocks Partially Overlap?

Because of what a block is. The number after the slash counts how many leading bits are fixed — the same information a subnet mask carries, written shorter — so 10.0.0.0/8 means "every address beginning 00001010". A block is a bit pattern, not a span somebody chose.

Now take two of them and compare their patterns. There are only two ways that can go.

The shorter pattern is a prefix of the longer one. Then every address matching the longer one also matches the shorter, so the smaller block sits wholly inside the bigger. Containment.

Or the patterns differ somewhere in the bits they share. Then no address can satisfy both at once, and the two blocks have nothing in common at all. Disjoint.

There is no third outcome. That is what makes CIDR a tree rather than a set of arbitrary ranges.

Ranges are the exception, and that is useful

A range is any two endpoints somebody typed, and it is under no obligation to line up with a bit boundary. 10.0.0.5 – 10.0.0.20 and 10.0.0.15 – 10.0.0.30 share .15 to .20, and neither contains the other. Genuine partial overlap.

Which turns a partial overlap into a finding rather than a warning. If this checker reports one, it is telling you the input was not CIDR-shaped — somebody wrote ranges, and any config that only accepts prefixes will have to reshape them first. The range to CIDR converter does that properly, and it usually produces more blocks than people expect.

Why any of this matters outside a maths lesson

Because "overlap" is a word that gets used for four different situations, and the response to each is different. A tool that reports them all as the same thing has left you with the work.

What Does Merging Actually Save You?

Rules. That is the answer almost every time, and it is worth being concrete about because rules are finite.

An AWS security group allows sixty inbound rules by default. Azure network security groups and GCP firewall rules have their own ceilings. A router's table is bounded by memory, and a longer table is a slower lookup. A hand-maintained allowlist that nobody can read is a list nobody audits.

Forty entries collapsing to twelve is twenty-eight rules back, and a list somebody can hold in their head.

Paste the list you actually have

Nobody keeps a clean list. Real allowlists are full of notes — # office, // legacy VPN, remove?, a ticket number beside the line somebody added under pressure. Firewall users have been asking their tooling to support exactly this for years, and most converters still choke on it.

So comments after #, // or ; are stripped, and kept. When the checker tells you a block is redundant it shows the note you wrote next to it, which is usually what decides whether it goes.

Whole comment lines are skipped and blank lines ignored. An allow or deny in front of a block is read and set aside, since this page compares addresses and not actions.

That last one matters for a practical reason. The same list will be doing something else on another page, and it should not have to be edited in between.

The word for this is aggregation

Merging blocks has a proper name and several of them. CIDR aggregation is the usual one, supernetting is the same operation seen from the other end of subnetting, and route summarisation is what routing people call it. All three describe collapsing many prefixes into fewer that cover the same space.

The concept is not a convention somebody invented for tooling. It is in the specification: RFC 4632 is titled the Internet Address Assignment and Aggregation Plan, and it is the document that replaced classful addressing with the prefix structure this whole page rests on.

Two kinds of merge, and only one is safe

The distinction matters more than the arithmetic.

• Exact merge. The smallest set of blocks covering precisely the addresses you had. Duplicates go, contained blocks are absorbed, adjacent pairs combine. Coverage is byte-for-byte identical, so it is safe to apply without reviewing what changed — because nothing did.
• Single supernet. One block covering everything, which almost always covers more besides. Simpler, and it silently admits addresses that were never on your list.

The page gives you both, and counts the extra addresses the supernet would let in. That number is the entire decision, so it is stated three ways rather than one.

• Zero extra. Your blocks already fill the supernet exactly. Take it — it is the same rule, written shorter.
• Fewer extra than you cover. A real trade-off. Read the number, look at whose space the remainder is, then decide.
• More extra than you cover. The page tells you not to use it. A block holding more addresses outside your list than inside it is not a simplification, it is a different rule with a much wider reach — and two unrelated networks will always produce one.

The other half of the audience is routing

Firewall cleanup is the common reason for landing here. The other one is the route table, and it is the reason aggregation exists at all.

A router advertising forty individual /24s to its neighbours is forty entries in every table that hears it, forty things to converge on when something changes. Advertised as a single aggregate, it is one. That is why BGP, OSPF and EIGRP all have summarisation built in, and why a network that never aggregates ends up slow in a way nobody can point at.

The same merged output serves both. A firewall wants fewer rules; a router wants fewer routes; an ACL wants both. What changes is only how much widening you will tolerate — a route can usually afford a supernet that covers some unused space, because it describes reachability. An allow rule cannot, because it describes permission.

Gaps: the thing that is missing rather than duplicated

The other finding worth having is the opposite of an overlap. If your blocks run from 10.0.0.0 to 10.0.3.255 but nothing covers 10.0.2.0/24, that quarter of the span is a hole.

Sometimes that is deliberate, and sometimes it is a subnet somebody forgot when the list was extended. Either way it is invisible in forty lines of config, so the checker reports the gaps inside your covered span as their own list. For designing the blocks in the first place rather than auditing them afterwards, the subnet calculator works out the sizes, and the CIDR calculator shows what any single prefix covers.