myip
🇬🇧 EN

IP ranges and CIDR

Paste any text. We find the addresses in it, merge what overlaps or touches, and return the smallest set of prefixes. Nothing leaves your browser.

Overlapping and adjacent blocks are merged: 10.0.0.0/25 together with 10.0.0.128/25 comes back as a single 10.0.0.0/24.

The problem this solves

Address lists arrive in whatever shape the thing that produced them felt like. A firewall exports prefixes, a ticketing system pastes ranges with a dash, a colleague sends a column from a spreadsheet, and a log gives you addresses buried in lines of text. Somewhere at the end of that there is a rule to write, and the rule wants CIDR blocks — as few of them as possible, because every extra line is another thing to review and another entry in a table that has a size limit.

So this page does three things in order. It finds every address, range and prefix in whatever you paste, ignoring the text around them. It merges everything that overlaps or touches. Then it splits the result back into the smallest set of CIDR blocks that covers exactly the same addresses — no more and, importantly, no fewer.

What it recognises

IPv4 and IPv6 are handled together and reported separately, because merging across families is meaningless: they are different address spaces that happen to be written on the same page.

A prefix is normalised to its own boundary before anything else happens. If you paste 192.168.1.50/26 — an address inside a block rather than the block itself — it is read as 192.168.1.0/26, which is the network that address actually belongs to and almost certainly what was meant.

Why "merge" includes blocks that merely touch

Overlapping blocks obviously collapse into one. Less obviously, so do adjacent ones: 10.0.0.0/25 and 10.0.0.128/25 are two halves of exactly 10.0.0.0/24, and returning them as two lines when one line says the same thing would be a worse answer, not a more faithful one. The merge therefore joins ranges when the next one starts at most one address after the previous one ends.

This is the step that does the real work on real input. Firewall exports and abuse feeds are full of blocks that were added at different times by different people and which, taken together, are simply a larger block.

What "smallest set" means, and why it is exact

Turning an arbitrary range into CIDR blocks is not a matter of taste. Given a range, there is exactly one minimal set of prefixes that covers it precisely, and the way to find it is mechanical: from the current start, take the largest block that is both aligned to that start and small enough to fit inside what remains, emit it, move the start past it, repeat.

Alignment is the part that surprises people. A /24 can only begin at a multiple of 256, so the range 10.0.0.5 - 10.0.1.20 does not become one or two round blocks — it becomes a staircase of small prefixes at the start, a large one in the middle and another staircase at the end. That is not the tool being unhelpful; that is what the range is. If the staircase is unwelcome, the fix is to choose range boundaries that fall on power-of-two boundaries.

How it stays fast on large input

The obvious implementation — expand every range into a list of addresses, sort them, remove duplicates, group them again — works beautifully on twenty addresses and freezes the tab on 10.0.0.0/8, which is sixteen million of them. A single /16 of IPv6 would be worse than any computer will ever handle.

Nothing here ever enumerates addresses. Every input becomes an interval — a pair of very large integers — and the merging and splitting operate on intervals. The cost depends on how many entries you paste, not on how many addresses they describe, which is why 0.0.0.0/0 and a single host cost the same.

Two ceilings still exist to protect the tab: a limit on how many entries are read from the text and a limit on how many prefixes are printed. If either is reached the page says so, with the numbers, instead of quietly returning a shorter answer. A truncated list that looks complete is the one genuinely dangerous failure mode for a tool like this — you would take it away and build a rule with a hole in it.

This is the page we most want to run in your browser

Of everything on this site, this is the tool people paste the most sensitive material into: raw log lines, firewall configuration, internal address plans. That material describes the inside of a network, and it should not leave the machine it is on merely because someone wanted to tidy up a list.

So there is no form here that submits, no request in the background, and no record of anything you paste — the entire operation is JavaScript in your tab. Load the page, disconnect the network, and it keeps working; that is the simplest way to confirm the claim without taking our word for it.

Frequently asked questions

How do I convert an IP range into CIDR blocks?

Paste the range in the form 10.0.1.0 - 10.0.1.255 and the smallest set of prefixes that covers it appears below. There is exactly one minimal answer for any range, found by repeatedly taking the largest block that is aligned to the current start and still fits in what remains, so the result is not a matter of preference.

Why does my range turn into so many prefixes?

Because a prefix must begin on its own boundary: a /24 can only start at a multiple of 256, a /26 at a multiple of 64. A range like 10.0.0.5 - 10.0.1.20 therefore needs a staircase of small blocks at each end and a large one in the middle. Nothing is wrong; that is the shape of the range. If you want round numbers, choose boundaries that fall on powers of two.

Can I paste raw log lines instead of a clean list?

Yes, that is the main use. Every address, range and prefix is picked out of the surrounding text and everything else is ignored, so output from iptables, an access log or a JSON dump works as it is. Things that merely look like IPv6 — clock times such as 12:34:56, MAC addresses — are tried and discarded, because a candidate that does not parse as an address is dropped rather than guessed at.

Why are 10.0.0.0/25 and 10.0.0.128/25 returned as one block?

Because together they are exactly 10.0.0.0/24 — the same addresses, said in one line instead of two. Merging joins ranges that overlap and also ranges that merely touch, since returning two lines where one is equivalent would be a worse answer rather than a more faithful one. This is what does most of the work on firewall exports assembled by several people over time.

Will a huge prefix like 10.0.0.0/8 freeze the page?

No, because addresses are never enumerated. Every entry becomes an interval of two large integers, and merging and splitting work on the intervals, so a /8 and a single host cost the same. The naive approach of expanding a range into a list would need sixteen million steps for that one prefix, which is exactly the implementation this page avoids.

What happens if I paste more than the tool will handle?

It reads a fixed maximum number of entries and prints a fixed maximum number of prefixes, and if either ceiling is reached it says so with the actual numbers. That message matters more than the limit: a truncated list that looks complete is the one dangerous failure for this kind of tool, because you would take it away and write a rule with a hole in it.

Can I mix IPv4 and IPv6 in the same input?

Yes. Both are recognised, counted separately and merged separately, because combining them would be meaningless — they are two different address spaces that happen to be written on the same page. The summary shows how many entries of each family were found so you can tell at a glance whether something was misread.

Does anything I paste here reach your server?

No, and this is the page where it matters most: people paste log lines, firewall rules and internal address plans, all of which describe the inside of a network. The whole operation is JavaScript in your browser — no form is submitted, no request is made and nothing appears in our logs. Disconnect the network after the page loads and it keeps working.

Related checks