Why two neighbouring blocks often refuse to merge
Aggregation is not "these are next to each other, so glue them". A CIDR block is defined by a starting address and a prefix length, and the starting address has to be a multiple of the block size. Two blocks collapse into one shorter prefix only when three things hold at once: they are the same size, they are next to each other with nothing in between, and the lower of the two starts on a boundary of the combined size.
The classic failure is 192.168.1.0/24 plus 192.168.2.0/24. They are the same size and they are contiguous, but 192.168.1.0 is not a multiple of 512, so the pair cannot be a /23. The /23 that contains 192.168.1.0 is 192.168.0.0/23, which also drags in all of 192.168.0.x. Write that into a firewall or a route and you have silently included 256 addresses nobody asked for. The pair that does merge is 192.168.2.0/24 plus 192.168.3.0/24, giving 192.168.2.0/23. This tool never widens a range: the blocks it prints cover exactly the addresses you gave it, and no others.
What overlap and adjacency each mean here
Two inputs overlap when they share at least one address, which usually means one is nested inside the other — 10.0.0.0/24 and 10.0.0.128/25 is the everyday case. That is not an error in itself, and it is common in a rule set that was edited by several people over several years, but it is worth seeing, because it usually means one of the two entries is doing nothing.
Adjacency is different: the ranges do not share an address, they merely touch. Adjacent entries get joined into a single range for counting purposes, then that range is re-expressed as the smallest correct set of prefixes. Sometimes that is one block, sometimes it is several. The tool reports adjacency separately from overlap so you can tell which situation you are looking at without counting octets.
Ranges that are not blocks at all
Plenty of real inputs are arbitrary ranges rather than clean prefixes. A DHCP pool of 172.16.4.10 to 172.16.4.60 does not start or end on a power-of-two boundary, so it is not one CIDR block and never will be. Expressed as prefixes it takes several: a /31 here, a /28 there, a /29 to finish. That expansion is exact — the blocks cover the range and nothing outside it — and it is what you need when a system accepts prefixes but the requirement was written as a range.
| Prefix | Addresses | Starts every |
|---|---|---|
| /32 | 1 | address |
| /31 | 2 | 2 addresses |
| /30 | 4 | 4 addresses |
| /29 | 8 | 8 addresses |
| /28 | 16 | 16 addresses |
| /27 | 32 | 32 addresses |
| /26 | 64 | 64 addresses |
| /25 | 128 | 128 addresses |
| /24 | 256 | whole third octet |
| /23 | 512 | even third octet |
| /22 | 1,024 | third octet divisible by 4 |
| /16 | 65,536 | whole second octet |
Reading down that last column is the fastest sanity check there is. If somebody hands you a /22 whose third octet is 5, it is wrong before you check anything else.
Host bits, and the entry that means something other than it says
An entry like 10.0.3.77/24 has bits set below the prefix. Different systems disagree about what to do with it: some reject it, some accept it and treat it as 10.0.3.0/24, and at least one popular parser has historically accepted it and kept the host bits, which produces a rule matching a single address instead of a whole subnet. This tool normalises to the block and tells you it did. When you see that warning, go back to the source and find out which behaviour the original system had, because the difference between a /24 and one address is the entire point of the rule.
What this does not do
No packet is sent, no address is resolved, and nothing is checked against a live routing table or registry — the arithmetic happens in the page, on the text you paste. A block being present in a list here says nothing about whether it is reachable, allocated, in use, or appropriate to put in any particular configuration. It is address arithmetic, and the operational judgement stays with you. For IPv6 notation, which follows different rules entirely, use the IPv6 address expander.
Questions people ask
Why did my two adjacent /24s not become a /23?
Because the lower one does not start on a /23 boundary. A /23 covers 512 addresses and must begin at a third octet that is even. 192.168.1.0 and 192.168.2.0 are contiguous but 1 is odd, so no /23 contains both and only both. The correct answer really is two blocks. If you want a single prefix covering both you have to accept a /22 starting at 192.168.0.0, which also covers 192.168.0.x and 192.168.3.x — 512 extra addresses that were not in your list.
Can I paste ranges rather than CIDR blocks?
Yes. A line of the form 10.0.0.20-10.0.0.90 is accepted, as is a bare address, which is treated as a /32. Ranges are merged and counted the same way as blocks, and the result is re-expressed as the smallest set of prefixes that covers exactly that span. An arbitrary range usually needs several prefixes, and the block list shows how many.
The tool says my input overlaps. Do I need to fix it?
Not necessarily. Overlap is a report, not a verdict. In a firewall rule set, an inner block is sometimes present deliberately because it carries a different action, and order of evaluation decides which wins. In a route summary or an allocation register, overlap usually means duplicated work or a stale entry. Look at what the list is for before deleting anything, and check whether the system reading the list is order-sensitive.
Does this handle a /0?
Yes, and it is worth knowing what it means. A /0 covers the entire IPv4 space, all 4,294,967,296 addresses, so if a /0 appears anywhere in your list every other line is redundant and the merged output collapses to that one block. That is arithmetically correct and almost never what was intended in a list of specific ranges. The same applies to a /1 or a /2, which is why the tool prints the covered address count next to the result.
Does it work with IPv6?
No. Everything here is 32-bit IPv4 arithmetic. IPv6 prefixes are 128 bits and cannot be held in a JavaScript number at all, and the conventions are different enough that reusing an IPv4 mental model gives confident wrong answers — there is no broadcast, /64 is the standard LAN, and prefix boundaries are usually nibble-aligned by convention. The IPv6 address expander handles notation on that side.