IP Range to CIDR Converter
and the Rules to Go With It
Give it a first and last address — or paste the whole range into one box — and get the minimal set of CIDR blocks that covers it exactly, IPv4 or IPv6. Then the part other converters leave you to do by hand: those blocks written out as firewall rules for iptables, ufw, the AWS CLI, Terraform, nginx or Cloudflare, plus an honest comparison against using one broader block instead.
0
CIDR blocks
0
Addresses covered
—
Family
—
Of an AWS SG's 60
The exact set
| CIDR | Network address | Broadcast address | Addresses |
|---|
Exact, or one broader block?
Exact — covers your range and nothing else
—
One block — simpler, but wider
—
Ready to paste
One range per line, written as start - end or start,end. This is the shape of a firewall migration or an allowlist export.
| Range | Blocks | CIDR |
|---|
Quick Answer: Why Does One Range Need Several CIDR Blocks?
Because every CIDR block holds a power-of-two number of addresses and must start on a boundary matching its own size. 192.168.1.10 to 192.168.1.50 begins and ends mid-boundary, so it takes several aligned blocks to cover it without spilling over.
Robert Harrison
OSINT and Network Utility Expert
Robert works on network diagnostics and the practical end of IP tooling — the conversions, lookups and calculations that sit underneath everything else.
The arithmetic here is settled. Every correct converter returns the same blocks, because there is exactly one minimal set for any range. So the interesting question is not what the blocks are — it is what you do with seven of them at four in the afternoon with a change window closing.
Which is why this page carries on past the answer. It writes the rules out for whichever thing you are configuring, it counts what those blocks cost against an AWS security group's sixty, and it shows you the one broader block you could use instead along with exactly how many extra addresses that would let in. That last number is the one worth seeing before you decide, and it is the one no converter shows you.
Last reviewed 25 August 2026 · Runs entirely in your browser · Nothing you type is sent anywhere
View all articles by Robert HarrisonWhy Can't an Arbitrary Range Be One CIDR Block?
First, worth asking where the range came from, because it explains why this job exists at all. Almost nobody writes a start and end address by choice. They arrive that way: a regional internet registry publishes an allocation as two addresses, a vendor sends over the range its servers use, a threat feed lists an attacker block as 185.220.101.0 – 185.220.101.255, an ISP documents a customer assignment. None of those are obliged to land on a clean prefix, and none of them do.
Then you have to put it into something that only speaks CIDR notation. Which brings us to the awkward part.
Because a CIDR block is not a range with two free ends. It is a fixed shape: a power-of-two number of addresses, starting on a boundary that matches its own size. A /24 holds 256 addresses and can only begin where the last octet is zero. A /28 holds 16 and can only begin at .0, .16, .32 and so on.
Give it a range that starts at .10 and ends at .50 and neither end lands on a useful boundary. So the range gets built out of pieces that do.
| Block | Covers | Size | Why this one |
|---|---|---|---|
| 192.168.1.10/31 | .10 – .11 | 2 | .10 is even but not a multiple of 4, so 2 is the largest that fits |
| 192.168.1.12/30 | .12 – .15 | 4 | .12 is a multiple of 4 |
| 192.168.1.16/28 | .16 – .31 | 16 | .16 is a multiple of 16, and 32 would overshoot |
| 192.168.1.32/28 | .32 – .47 | 16 | same again |
| 192.168.1.48/31 | .48 – .49 | 2 | only 3 addresses left, so 2 then 1 |
| 192.168.1.50/32 | .50 | 1 | the last address on its own |
Six blocks for forty-one addresses. The pattern is always the same: small blocks at the ragged ends, larger ones through the aligned middle. A range that happens to start and end on clean boundaries collapses to one block, which is why 10.0.0.0 to 10.255.255.255 is simply 10.0.0.0/8.
Each block's first address is its network address and its last is the broadcast address — those are the two columns beside every block in the results. The prefix length is the same information as a subnet mask, written shorter: /24 and 255.255.255.0 say the identical thing, that the top twenty-four bits are fixed. Collapsing several small prefixes into one larger one is supernetting, and doing it to a routing table is route summarisation — same arithmetic, different reason.
Paste it however you have it
Ranges do not arrive as two tidy fields. They arrive as 192.168.1.10 - 192.168.1.50 in the middle of a ticket, or as a CIDR block somebody wants expanded and re-cut. Both go into the first box and get sorted out — a dash, a comma or the word to all split, and a CIDR is read as the range it covers.
Zero-padded addresses are the one thing refused rather than guessed at. 192.168.001.010 is ambiguous, because a leading zero means octal to some parsers and nothing to others, so the page says so instead of picking an interpretation.
The algorithm, in one sentence
Stand at the first address, take the largest block that both starts there and does not run past the last address, write it down, move to the address after it, and repeat until you arrive at the end. That greedy walk is provably minimal — it is the same procedure behind Python's summarize_address_range(), and it is why every correct tool gives you the same answer.
Going the other way? That is the inverse operation and it lives on the CIDR calculator, which takes a block and tells you the range, host count and boundaries it covers. Use this page to build a rule from a range somebody gave you; use that one to check what a rule you already have actually permits. For the mask arithmetic underneath both, the subnet calculator is the page.
How Do You Turn Those Blocks Into Actual Rules?
This is where most converters stop and the work starts. Six blocks means six rules, and every platform wants them written differently.
The tool emits them for you, but the shapes are worth knowing because the differences are not cosmetic:
- iptables and ufw take one address specification per rule, and order matters — evaluation stops at the first match.
- AWS security groups take one CIDR per rule and are allow-only. There is no deny rule to write, which changes how you think about the exact-versus-broader question below. Azure network security groups and GCP firewall rules both accept a list of prefixes in a single rule instead, so the same six blocks cost you one rule there rather than six — the quota maths below is an AWS VPC problem specifically.
- Terraform accepts a list in a single resource, so six blocks is one block of configuration rather than six — but it is still six rules once applied, and the quota counts what is applied.
- nginx uses
allowanddenydirectives that inherit down the config tree, so where you put them matters as much as what they say. - Cloudflare IP access rules take one entry each and are evaluated as a set rather than in order.
Check what space the range is in first
Before any of this matters, it is worth knowing what you are about to allow. A range inside RFC 1918 private space, loopback, link-local, carrier-grade NAT, multicast or one of the documentation blocks is flagged above with the block it falls in.
None of that is an error. An internal rule allowing 10.0.0.0/8 is completely ordinary. The same rule on an internet-facing group is not, and 169.254.0.0/16 in particular is where the cloud metadata endpoint lives — the thing an SSRF filter exists to protect. A converter that hands you blocks without mentioning any of that has just helped you build the wrong rule faster.
Exact blocks or one broader one?
The honest answer is that it depends on what sits in the gap, and that is a question only you can answer. What the tool can do is tell you exactly how large the gap is.
Take 203.0.113.100 to 203.0.113.200. The exact set is several blocks. The smallest single block containing the whole range is 203.0.113.0/24, which is one rule instead of several — and it also admits 203.0.113.0 through 203.0.113.99 and 203.0.113.201 through 203.0.113.255. That is 155 addresses you did not ask for.
AWS's own guidance recommends combining rules with broader blocks to stay inside the quota — and attaches the caveat that matters. Only summarise when every address in the wider block should have the same access. In an allow rule, those 155 extra addresses are 155 hosts you have just permitted. If the range came from a vendor and the neighbouring space belongs to someone else, that is not a tidying-up exercise.
If the range came out of a threat feed or an access log rather than a vendor, it is worth checking what is in it before writing any rule at all. The bulk bot checker will tell you which addresses are genuine search crawlers, and a network lookup tells you who a block belongs to.
What Do Those Blocks Cost You in Rule Quota?
One rule each, and rules are finite. This is the constraint that turns an arithmetic question into an engineering one, and no other converter mentions it.
On AWS, the documented default quota is 60 inbound and 60 outbound rules per security group, with IPv4 and IPv6 counted separately. A range that summarises into 40 blocks has spent two thirds of your inbound budget before you have configured anything else.
Above that sits a harder ceiling: 1,000 combined rules per network interface. Raising the per-group quota does not create capacity, it moves it — AWS reduces the groups-per-interface quota to compensate, because the product of the two cannot exceed 1,000. Ask for 250 rules per group and you are down to four groups per interface.
Managed prefix lists are not the escape hatch they look like. A prefix list counts against your quota by its maximum entries setting, not by how many entries it actually contains. Create one with room for 100 and it costs 100 rules while holding five. It is genuinely useful for keeping a shared list maintainable in one place, and it buys you no headroom at all.
The counter above shows what your conversion costs against that sixty, and says so loudly once a single range would eat a serious fraction of it. Other platforms have their own ceilings — the point is not the specific number but that there is one, and that a converter which only hands you blocks has quietly handed you a bill as well.
What to do when the count is too high
- Use the broader block, having read the number of extra addresses and decided you are content with them.
- Split the range across more than one security group, which multiplies your rule budget while the per-interface ceiling allows it.
- Move the filtering somewhere built for volume — a network ACL, a WAF, or an application-layer allowlist — rather than expressing everything as security group rules.
- Check whether the range is really the unit you need. A list of individual addresses that happens to span a wide range is a different problem, and sorting it first usually shows where the real clusters are.
- Before changing anything, confirm what the current rules already cover. The IP in CIDR checker tests an address against a whole allowlist and names the rule that fires first.
What this tool cannot do
It converts a range and writes the rules. The judgement stays with you.
It only goes one direction
Range in, blocks out. Expanding a block back into a range is the inverse job and belongs on the CIDR calculator. Keeping them apart is deliberate: a page that does both tends to leave people unsure which way they just went.
It does not merge separate ranges
Each range is summarised on its own, including in the list tab. Two adjacent ranges that could combine into one block stay as two sets, because collapsing across inputs is aggregation rather than conversion.
The rules are a starting point
Generated syntax assumes a plain allow on a default chain or group. Ports, protocols, interfaces, rule order and whatever else your environment needs are yours to add, and the surrounding config decides whether a rule fires at all.
Quotas move
The sixty-rule figure is the AWS default at the time of writing and is adjustable on request. Treat the counter as a prompt to check your own account rather than as the last word on it.
To see why a block has to start where it does, the binary converter makes the boundary visible — every prefix length is just a count of fixed leading bits.
Frequently asked questions about range to CIDR conversion
Where do start-and-end IP ranges even come from?
Almost nobody writes one by choice. Regional internet registries publish allocations as two addresses, vendors send the range their servers sit in, threat feeds list attacker blocks as 185.220.101.0 – 185.220.101.255, and ISPs document customer assignments the same way. None of them are obliged to land on a clean prefix. Then whatever you are configuring only accepts CIDR notation, so the range has to be converted.
How do I convert an IP range to CIDR?
Enter the first and last address above. The converter finds the largest CIDR block that starts exactly at your first address without running past your last, emits it, moves to the next address after it, and repeats. What comes out is the smallest possible set of blocks that covers your range and nothing beyond it.
Why does my IP range need more than one CIDR block?
Because a CIDR block cannot start anywhere. Every block holds a power-of-two number of addresses and has to begin on a boundary that matches its own size — a /24 holds 256 addresses and must start where the last octet is zero. An arbitrary range like 192.168.1.10 to 192.168.1.50 starts and ends in the middle of those boundaries, so it has to be built out of several smaller blocks that each line up.
What is the minimal set of CIDR blocks?
The fewest blocks that cover every address in your range and no address outside it. There is exactly one such set for any given range, so every correct tool produces the same answer — this is arithmetic rather than a matter of approach. The greedy method used here is the same one behind Python’s summarize_address_range().
Can I use one bigger block instead of several exact ones?
Often yes, and sometimes you should. The page shows both: the exact set, and the single smallest block that contains your whole range, with a count of how many extra addresses that block would let through. AWS’s own guidance recommends combining rules with broader blocks — with the caveat that matters, which is that every address in the wider block must be one you are happy to grant the same access.
How many rules does this use in an AWS security group?
One per block. The default quota is 60 inbound and 60 outbound rules per security group, counted separately for IPv4 and IPv6, so a range needing 40 blocks consumes two thirds of your inbound budget before anything else is configured. There is also a hard ceiling of 1,000 combined rules per network interface, and raising the per-group quota forces the groups-per-interface quota down to compensate.
Do managed prefix lists get around the rule limit?
Less than people expect. A prefix list counts against the quota by its maximum entries setting rather than by how many entries it currently holds, so a list created with room for 100 costs 100 rules even while it holds five. It is still worth using for maintainability, but it is not extra capacity.
Does this work for IPv6?
Yes, using the same algorithm on 128-bit arithmetic. Both ends have to be the same family — an IPv4 start with an IPv6 end is not a range, it is two unrelated addresses. IPv6 ranges frequently reduce to a single block, because the space is vast enough that allocations tend to land on clean boundaries.
What is the difference between this and a CIDR calculator?
They are inverse operations. This page goes range → CIDR: you give it a first and last address and it summarises them into blocks. A CIDR calculator goes the other way, expanding a block into the range and host count it covers. Use this one to build a rule from a vendor-supplied range, and the calculator to check what a rule you already have actually permits.
Can I convert several ranges at once?
Yes. The list tab takes one range per line, written as start - end or start,end, up to 500 of them. That is the shape of a firewall migration or an allowlist audit, where the input is usually a whole column exported from somewhere rather than a single pair.
Can I just paste the whole range into one box?
Yes. 192.168.1.10 - 192.168.1.50 pasted into the first field gets split across both, and so do the comma and the word to as separators — because that is how ranges arrive in tickets and vendor emails. A CIDR block pasted in is expanded to its first and last address instead, which is a shorthand for the range you already meant rather than the reverse operation.
Does it warn about private or reserved ranges?
Yes, and it should. If your range sits in RFC 1918 private space, loopback, link-local, carrier-grade NAT, multicast or documentation space, the page says so and names the block. That is fine for an internal rule and usually wrong for one facing the internet — and a converter that stays quiet about it has helped you build the wrong rule faster. Partial overlaps are flagged as partial rather than reported as if the whole range were special.
Is the range sent to a server?
No. Everything runs in your browser in JavaScript, so nothing you type is transmitted or logged. Internal address ranges are exactly the sort of thing people paste into a converter without thinking about it, which is why this one has nowhere to send them.
Related IP tools
The rest of the addressing toolkit.
Browse the full set on the TrustMyIP tools directory.
Last updated 25 August 2026 · Runs in your browser · Nothing you type is sent anywhere