Visual Subnet Calculator & CIDR Range Validator
Plan IPv4 and IPv6 networks visually, calculate usable ranges, split subnets, and catch overlap mistakes before they break your cloud architecture.
Cloud provider preset (affects usable IP counts)
This tool runs entirely in your browser. All CIDR calculations, provider logic, splitting, and overlap checks happen client-side. Nothing you enter is stored or sent to any server.
Overview
CIDR planning is still one of the most error-prone parts of cloud infrastructure. Even experienced engineers miscalculate usable IP counts, forget that cloud providers reserve additional addresses, or accidentally deploy overlapping subnets that break VPC peering. The numbers are straightforward in theory, but in practice they combine prefix math, provider-specific reservation rules, and routing constraints in ways that are easy to get wrong.
This tool combines range calculation, subnet splitting, overlap checking, and provider-aware reserved-IP logic into a single interface. Instead of switching between separate calculators and reference docs, you can plan a VPC layout, compare usable counts across AWS, Azure, and Google Cloud, split blocks into subnets, and verify there are no conflicts — all in one place.
Visual mapping makes the difference between reading that a /22 contains 1024 addresses and actually seeing the four /24 blocks it divides into. For smaller subnets, the per-address view highlights exactly which IPs are reserved and which are assignable under each provider model — making it much harder to misconfigure a deployment.
What this tool helps with
Good fit for
- Calculating IPv4 subnet rangesget network address, broadcast, masks, first/last usable, total and provider-specific usable counts for any CIDR block.
- Understanding IPv6 prefixessee compressed and expanded forms, /64 subnet counts, and provider-specific notes for IPv6 ranges.
- Splitting large VPC blocks into smaller subnetsdivide a /22 into /24s, a /20 into /24s, or any valid split — with one-click copy of the resulting list.
- Checking for overlapping CIDRs before peeringdetect identical, contained, and partially overlapping ranges before they cause routing conflicts in peered or routed networks.
- Comparing standard math with cloud provider reserved-IP rulessee how AWS, Azure, and Google Cloud each reduce the usable count differently from the same CIDR block.
- Learning subnetting for certifications and interviewsuse the binary breakdown and visual range map to understand how prefix length determines network vs host bits.
Common pitfalls to avoid
- Assuming .0 and .255 are always the only reserved addressescloud providers reserve additional addresses. AWS and Azure reserve 5, GCP reserves 4. This tool shows exactly which addresses are reserved for each provider.
- Using overlapping ranges across VPCs or VNetsoverlapping subnets break peering, VPN routing, and on-prem integrations. Always run an overlap check before deploying.
- Choosing subnets that are too small for future growtha /28 with 11 usable addresses (AWS) fills up quickly. Plan for growth by choosing a larger prefix than the minimum.
- Treating IPv6 like IPv4IPv6 has no broadcast address, uses different prefix conventions, and cloud providers impose their own subnet sizing rules (/64 for most).
How to use it
- 1
Enter a CIDR block or choose a preset
Type an IPv4 or IPv6 CIDR block, or click one of the sample presets to load a common VPC or subnet size.
- 2
Select a cloud provider preset
Choose Standard (RFC math), AWS VPC, Azure VNet, or Google Cloud VPC. The provider preset changes how reserved IPs are calculated.
- 3
Review the visual range map and calculated details
Inspect per-address, block-based, or summary views depending on subnet size. Check reserved addresses, usable counts, and binary breakdowns.
- 4
Split the block into smaller subnets if needed
Switch to the Subnet Splitter tab. Enter a source CIDR and target prefix to see the resulting subnet list.
- 5
Run the overlap checker against another block
Switch to the Overlap Checker tab. Enter two CIDR blocks to detect conflicts before peering or routing changes.
- 6
Copy or export the result
Use the copy buttons on any value or the full subnet list. Results are formatted for direct use in Terraform, CloudFormation, or documentation.
Common issues and fixes
Assuming .0 and .255 are always unusable
In standard networking, the network address (.0) and broadcast address (.255 for a /24) are reserved. But cloud providers reserve additional addresses. AWS and Azure reserve the first 4 and last 1 (5 total). GCP reserves first 2 and last 2 (4 total). Always check provider-specific counts.
Forgetting cloud providers reserve additional IPs
Switch to the relevant cloud provider preset (AWS, Azure, or GCP) to see the actual assignable count. A /24 gives 254 usable in standard math but only 251 in AWS/Azure and 252 in GCP.
Using overlapping ranges across VPCs or VNets
Run the Overlap Checker before deploying peered VPCs or VPN connections. Even a /24 fully contained within a /16 will cause routing ambiguity.
Choosing subnets that are too small
A /28 has only 16 total addresses — and only 11 usable in AWS. Plan for growth. Use the cloud comparison view to see how many IPs you actually get.
Treating IPv6 like IPv4
IPv6 does not have a broadcast address. The last address is a valid host. Cloud providers require /64 subnets. Do not try to apply IPv4 reservation logic to IPv6.
Expecting an IPv6 broadcast address
IPv6 eliminated broadcast in favor of multicast. This tool correctly omits the broadcast field for IPv6 calculations.
Forgetting provider subnet-size constraints
Azure requires IPv6 subnets to be exactly /64. AWS assigns /56 to VPCs and /64 to subnets. GCP uses /64 for dual-stack. Check provider documentation for current constraints.
Frequently asked questions
Related
What is a CIDR block and how do I calculate a subnet mask?
CIDR (Classless Inter-Domain Routing) notation describes an IP address range using a prefix length. For example, 10.0.0.0/24 means the first 24 of the 32 bits are fixed (the network portion), and the remaining 8 bits are available for host addressing. This gives 256 total addresses (2^8).
The subnet mask is derived directly from the prefix length. A /24 maps to 255.255.255.0 — the first 24 bits are all 1s, the remaining 8 are 0s. A /22 maps to 255.255.252.0 (22 bits of 1s, 10 bits of 0s = 1024 total addresses). The wildcard mask is the bitwise inverse of the subnet mask.
What is the difference between total IPs and usable IPs?
Standard subnet math gives you the raw address count (2^host-bits) and the classic usable count (total minus 2, for network and broadcast). But in cloud environments, the provider reserves additional addresses for infrastructure services — gateways, DNS resolvers, and future use.
For example, a /24 (256 total) gives 254 usable in standard math. But AWS and Azure reserve 5 addresses (first 4 + last 1), leaving 251 assignable. Google Cloud reserves 4 (first 2 + last 2), leaving 252. The difference matters when capacity planning: a /28 (16 total) drops from 14 standard-usable to only 11 in AWS.
Cloud subnetting cheat sheet
| Prefix | Mask | Total | Standard | AWS/Azure | GCP |
|---|---|---|---|---|---|
| /16 | 255.255.0.0 | 65,536 | 65,534 | 65,531 | 65,532 |
| /20 | 255.255.240.0 | 4,096 | 4,094 | 4,091 | 4,092 |
| /22 | 255.255.252.0 | 1,024 | 1,022 | 1,019 | 1,020 |
| /23 | 255.255.254.0 | 512 | 510 | 507 | 508 |
| /24 | 255.255.255.0 | 256 | 254 | 251 | 252 |
| /27 | 255.255.255.224 | 32 | 30 | 27 | 28 |
| /28 | 255.255.255.240 | 16 | 14 | 11 | 12 |
AWS and Azure both reserve 5 addresses per IPv4 subnet (first 4 + last 1). Google Cloud reserves 4 (first 2 + last 2) in primary ranges. Always verify current provider documentation for the latest reservation rules.
How subnet overlap breaks cloud networking
When two VPCs, VNets, or on-premises networks use overlapping CIDR ranges, routing becomes ambiguous. A packet destined for an IP in the overlap cannot be routed deterministically — the network stack does not know which network the address belongs to.
This breaks VPC peering, VPN tunnels, Transit Gateway attachments, and on-premises integrations. The fix usually requires re-addressing one or both networks — which means downtime, re-deployment, and potentially breaking dependent services. Catching overlaps early, before deployment, is significantly cheaper than redesigning later.
Common overlap scenarios include: a /24 fully contained within a /16 (containment), two /24s sharing the same network address (identical), and adjacent blocks that were miscalculated to partially overlap. The Overlap Checker detects all of these.
IPv4 vs IPv6 subnet planning
IPv6 uses prefixes differently from IPv4. The address space is 128 bits instead of 32, so even a /64 contains 2^64 addresses — more than the entire IPv4 address space squared. There is no IPv6 broadcast address; IPv6 uses multicast instead.
Cloud providers impose their own subnet sizing rules. AWS assigns /56 IPv6 blocks to VPCs and /64 to subnets. Azure requires IPv6 subnets to be exactly /64. Google Cloud dual-stack subnets use /64 internal ranges with configurable external IPv6 access types.
When working with IPv6, human-readable explanations are more useful than raw numbers. Saying "2^64 addresses" or "256 /64 subnets in a /56" communicates scale better than printing 18,446,744,073,709,551,616. This tool uses readable labels for large IPv6 address counts.
Cloud provider reserved-IP behavior
Cloud reservation rules are deployment-environment rules, not universal subnet math. Always use the relevant provider preset when planning cloud infrastructure to see accurate assignable counts.