IP Range Calculator
Determine all IP addresses contained within an IP start and end range.
IP Range Calculator
Runs entirely in your browser
This tool executes locally using standard browser APIs (for example window.crypto.getRandomValues or crypto.subtle where applicable). Your input is not transmitted to or stored on a ScriptPulse server. See How Calculations Work.
What This Tool Does
- The IP Range Calculator takes an arbitrary start and end IPv4 address — a raw range that may or may not align to a single CIDR block — and determines everything useful about it: the total number of addresses it contains, and the minimal set of CIDR blocks needed to exactly represent that range. This solves a specific, common problem: real-world IP ranges rarely arrive pre-formatted as clean CIDR notation. Cloud providers publish service IP ranges as start-end pairs, legacy firewall rules are often written the same way, and ISP allocation letters frequently list a plain address range rather than a prefix.
- The reason this needs its own calculation, rather than just picking the smallest CIDR block that happens to contain both endpoints, is that an arbitrary range usually can't be expressed as a single valid CIDR block at all. 192.168.1.10 through 192.168.1.20 spans 11 addresses, but no single CIDR block starts at .10 and ends at .20 — the tool has to decompose the range into the minimal set of aligned blocks that together cover exactly those addresses, no more and no less.
- This is the same underlying alignment problem the CIDR Aggregator solves for a list of existing blocks, applied instead to a raw address range as the starting point — useful specifically when you're handed a range rather than a pre-existing list of subnets to combine.
How It Works
- The start and end IPv4 addresses are each converted to their 32-bit integer representation.
- The tool confirms the end address is not earlier than the start address, and computes the total address count as the simple difference plus one.
- Starting from the first address, the tool finds the largest CIDR block that both starts at the current address and does not extend past the end of the range, emits that block, and advances past it.
- This repeats — finding the next largest valid aligned block from the new current position — until the entire range is covered, producing the minimal list of CIDR blocks.
- Results are presented as both the raw address count and the resulting CIDR block list, so you can use whichever form your target system (router config, firewall rule, documentation) actually needs.
Usage
- Enter the start IP address and the end IP address defining the range.
- Run the calculation.
- Review the total address count and the resulting minimal list of CIDR blocks that exactly covers the range.
- Use the CIDR block list directly in router, firewall, or cloud security group configuration, or the raw count for capacity planning.
- If the range doesn't decompose into a single block, use each listed block individually rather than trying to force the whole range into one prefix.
Examples
- Converting the range 192.168.1.10–192.168.1.20 (11 addresses) into its minimal CIDR representation: several small aligned blocks, since no single block fits those exact boundaries.
- Converting a cleanly-aligned range like 10.0.0.0–10.0.0.255 into the single equivalent block 10.0.0.0/24.
- Calculating that a published cloud provider range spanning 1,024 addresses corresponds to a single /22 block, confirming the expected allocation size.
- Checking whether a newly-documented partner IP range overlaps with an existing internal allocation by comparing their decomposed CIDR block sets.
Real-World Use Cases
- Converting a cloud provider's published service IP range (commonly listed as a start-end pair) into CIDR blocks usable in firewall or security group rules.
- Interpreting a legacy firewall rule or ISP allocation letter that specifies a raw address range instead of CIDR notation.
- Determining exactly how many addresses a documented range actually contains before requesting or provisioning it.
- Auditing whether two documented IP ranges from different sources actually overlap, by converting both to their canonical CIDR block sets first.
Best Practices
- When a system will accept only CIDR notation but you've been given a raw range, always decompose it properly rather than approximating with one oversized block that would incorrectly include addresses outside the original range.
- Where possible, ask upstream providers or partners for CIDR notation directly instead of a raw range — it avoids this conversion step entirely and removes any ambiguity about the exact boundaries.
- When a range decomposes into many small blocks, treat that as a signal the range wasn't allocated on clean boundaries — worth flagging if you control the allocation and can renumber it to something more aggregatable.
- Keep the original documented range alongside its calculated CIDR block list in your records, so future audits can trace the CIDR blocks back to their documented source.
Common Mistakes
- Rounding a raw range up to the nearest single CIDR block that contains both endpoints, which silently includes extra addresses that were never actually part of the original allocation.
- Assuming every range decomposes into exactly one CIDR block — most arbitrary ranges require several, and forcing a single-block answer produces an incorrect result.
- Confusing this tool's purpose with the CIDR Aggregator's — aggregation combines a list of existing, already-valid CIDR blocks; this tool starts from a single raw start-end range that isn't in CIDR form yet.
- Miscounting the address total by forgetting the range is inclusive of both endpoints — the count is (end minus start) plus one, not just the difference.
Limitations
- This tool covers IPv4 ranges; for IPv6, prefix planning is generally done directly in CIDR terms rather than raw address ranges, so use the IPv6 Subnet Calculator instead.
- It calculates the range's address count and minimal CIDR decomposition from the addresses you provide — it has no way to verify those addresses are actually allocated to you or routable.
- A start address later than the end address is treated as invalid input rather than silently reversed, since that ordering usually indicates a data-entry mistake worth surfacing rather than guessing the intent.
Technical Reference Guide
- CIDR notation and the variable-length subnet masking this decomposition relies on are defined by RFC 4632.
- The minimal-block decomposition follows the same alignment rule as CIDR aggregation: a block is only valid if its network address is evenly divisible by its own size, which is why arbitrary ranges typically require more than one block to represent exactly.
- Private IPv4 ranges frequently seen in these calculations are defined by RFC 1918: 10.0.0.0/8, 172.16.0.0/12, and 192.168.0.0/16.
FAQ
Why can't every IP range be written as one CIDR block?
A CIDR block's starting address must be evenly divisible by its own size — an arbitrary start and end address usually doesn't satisfy that condition, so the range has to be represented as several smaller, correctly-aligned blocks instead of one.
How is the total address count calculated?
It's the end address minus the start address, plus one — the range is inclusive of both endpoints, so subtracting alone would undercount by exactly one address.
What's the difference between this tool and the CIDR Aggregator?
This tool starts from a single raw start-end address range and decomposes it into CIDR blocks. The CIDR Aggregator starts from a list of existing CIDR blocks and combines adjacent, aligned ones into fewer, larger blocks. Different starting data, related underlying math.
Can I use this to check if two IP ranges overlap?
Yes — convert both ranges to their CIDR block form and compare, or check whether either range's start or end address falls within the other's boundaries.
Why did my range produce five separate CIDR blocks instead of one?
This means the range's start and end addresses don't fall on boundaries that allow a single-block representation — the tool returns the minimal set of blocks that exactly covers the range without including any address outside it.
Does this tool work with IPv6 ranges?
No — it's built for IPv4 start-end ranges specifically. For IPv6 subnet planning, use the IPv6 Subnet Calculator, which works directly in CIDR/prefix terms.
Part of this Developer Hub
This utility is part of our comprehensive Networking & Infrastructure topic workspace.
Explore foundational guidelines, technical specifications, and other interactive utilities related to this workflow.
Related Tools
Explore related utilities inside the Network Operations Lab workshop for complementary engineering workflows.
View all Network Operations Lab tools