IPv4 / IPv6 Subnet & CIDR Calculator: Conversions

Convert Hosts to CIDR

How to convert Hosts to CIDR

Calculating the right CIDR prefix for your host count adds 2 to account for the network and broadcast addresses, then finds the smallest power of 2 that covers the result. The prefix is 32 minus the number of host bits required.¹

Common Hosts to CIDR conversions

Why host count math is fixed

IPv4 address space is binary, so every subnet boundary falls on a power of 2. Designing around this constraint means you cannot create a subnet for exactly 50 hosts without wasting some space. The smallest prefix covering 50 hosts is /26, which provides 2^6 − 2 = 62 usable addresses.¹ Building on this, the formula h → 32 − ⌈log₂(h + 2)⌉ derives the minimum prefix length needed. Adding 2 to the host count before taking the ceiling accounts for the reserved network and broadcast addresses, and this step is the most common source of off-by-two errors in manual subnet planning. Consequently, the result is always the most compact subnet that holds all requested hosts without cutting off any addresses.

How IPv4 and IPv6 handle host ranges differently

In IPv4, two addresses per subnet are unavailable: the network address (all host bits zero) and the broadcast address (all host bits one).² A /24 provides 256 total addresses but only 254 usable. Furthermore, AWS and Azure reserve 5 addresses per subnet (not 2), so cloud deployments require adding 5 to the host count before applying the formula: h + 5 rather than h + 2.³ IPv6 has no broadcast mechanism, so every address in a /64 is usable,⁴ but the standard practice of using /64 for all segments means the hosts-to-prefix formula is rarely applied to IPv6. Conversely, on-premises networks follow the standard RFC math.

Practical subnet planning to avoid address exhaustion

Address exhaustion in a cloud subnet requires either migrating all workloads to a larger subnet or adding a secondary CIDR block, and both operations are disruptive. Planning 20 to 30 percent headroom into initial subnet sizing avoids this. For a team expecting to grow from 40 to 60 instances over 18 months, the 40-instance plan would choose /26 (62 usable, 57 after AWS reservations), which exhausts at 57 instances. Adding 30% headroom and choosing /25 (126 usable, 121 after reservations) accommodates 60 instances with room to spare. Use this formula to find the right prefix, then check the usable count against your cloud provider's reservations before committing.

Cloud provider reservation patterns and their impact on sizing

AWS, Azure, and GCP each modify the standard hosts-to-CIDR formula. AWS reserves 5 addresses per subnet: .0 for network, .1 for VPC router, .2 for Route 53 DNS resolver, .3 for future use, and the last address for broadcast. Azure follows the identical reservation pattern. GCP reserves 4 addresses per subnet: the first two and the last two.⁵ Building on this, for a workload needing 50 hosts, the standard math says /26 (62 usable), but on AWS the /26 provides only 57 usable addresses after the 5-reservation deduction. That 5-address gap pushes you to /25 (123 usable on AWS) to maintain comfortable headroom.

When cloud reservations change your prefix selection

Always account for provider reservations before selecting a prefix. A /28 provides 14 usable hosts under standard math but only 9 after AWS or Azure reserves 5. GCP gives 10 usable from a /28. Subnets smaller than /27 are especially risky in cloud environments: a /28 in AWS with only 9 usable addresses can exhaust after a handful of deploys if your autoscaling group grows. The calculator applies the correct reservation count for each cloud provider's defaults.

GCP also enforces a hard floor on subnet size: the minimum primary range is /29 (8 total addresses, 4 usable after GCP's reservations), so the hosts-to-CIDR formula cannot return anything longer than /29 for a Google Cloud primary range even if the requested host count is small enough to fit in a /30 or smaller under standard math. Secondary ranges are the exception, since GCP does not reserve any addresses within them, so a small secondary range yields more usable addresses than the same-sized primary range.

Reverse-engineering subnet sizes from existing infrastructure

Auditing an existing network often means determining what prefix was used given only the number of active hosts. A subnet with 120 active hosts most likely uses a /25 (126 usable): anything smaller would be full, and anything larger wastes address space. When performing a network migration from on-premises to cloud, reverse-engineer each existing subnet's size first, then add the cloud provider's reservation offset before selecting the target CIDR.

Converting flat network scans to CIDR allocations

Network discovery tools like Nmap return lists of active IP addresses. Grouping these into contiguous CIDR blocks simplifies firewall rule creation and documentation. An algorithm that sorts active IPs, identifies contiguous ranges, and outputs the smallest covering CIDR blocks transforms a raw scan into an address plan. Python's ipaddress.summarize_address_range() performs this grouping automatically, and CapyToolkit generates the same groupings interactively for any range of addresses.

Supernetting and route summarization with CIDR arithmetic

Route summarization reduces the number of entries in routing tables by combining adjacent CIDR blocks into a single covering prefix.⁶ Four contiguous /24s (for example 10.0.0.0/24 through 10.0.3.0/24) summarize to 10.0.0.0/22. Building on this, BGP route advertisements use summarization to keep global routing tables manageable: an ISP that allocates contiguous /20s to customers can advertise those /20s directly rather than listing every constituent /24. Variable-length summarization (not limited to power-of-2 block counts) follows the same bitwise logic: find the longest common prefix bits across all blocks, and that prefix length is your summary route.

When summarization causes blackhole routes

Over-aggressive summarization creates blackhole routes. If 10.0.0.0/22 is advertised as a single route but only 10.0.0.0/24 and 10.0.1.0/24 are actually in use, traffic destined for 10.0.2.x and 10.0.3.x gets forwarded to a destination that drops it. Documenting which addresses inside a summarized block are reachable versus allocated-but-empty prevents this failure mode. Static null routes for the empty subnets, pointing to a discard interface, ensure unreachable traffic is dropped cleanly rather than looping.

Try in the tool

Convert CIDR to host count

How to convert CIDR to host count

Calculating the usable host count from a CIDR prefix raises 2 to the power of the host bits (32 minus the prefix length), then subtracts 2 for the network and broadcast addresses.¹

Common CIDR to host count conversions

Why host count math is fixed

IPv4 subnet sizes are powers of 2 by definition. A prefix of /n reserves n bits for the network, leaving 32 − n bits for hosts. The total address count is 2^(32−n). Subtracting 2 for the reserved network and broadcast addresses gives the usable host count. Building on this, the formula is exact and not an approximation. A /26 always has 2^6 = 64 total addresses and 62 usable hosts,¹ regardless of the starting address. Consequently, you can look up any prefix in the table and get the precise count for firewall rules, DHCP pool sizes, and cloud subnet configuration without mental arithmetic.

How IPv4 and IPv6 handle host ranges differently

IPv4 subtracts 2 from the address count: one for the network address, one for the broadcast. IPv6 has no broadcast address, so all 2^(128−n) addresses in a subnet are theoretically usable,² but standard /64 segments contain 2^64 addresses, a number so large that no existing tool can enumerate it in practice.

How cloud providers override the standard formula

Cloud providers override the standard math further: AWS and Azure each reserve 5 addresses per subnet.³ A /24 in AWS provides 256 − 5 = 251 usable addresses rather than the standard 254. Furthermore, the formula applies only to IPv4 when accounting for cloud reservations; subtract 5 instead of 2 when planning VPC subnets in either provider. This adjustment matters most in small subnets, where the 3-address difference between standard and cloud math can push you to the next larger prefix.

Practical subnet planning to avoid address exhaustion

A /28 (14 usable hosts) fits most specialty subnets, such as database servers, load balancers, and VPN endpoints, without wasting addresses. Yet a /28 in AWS provides only 11 addresses after the 5 AWS-reserved ones. If you're placing more than 8 instances, a /27 (27 usable in AWS) is safer. For production application subnets expected to scale, a /24 (251 usable in AWS) provides room to run hundreds of microservices without a subnet migration. Building on this, EKS pod CIDRs need much larger blocks because a /22 provides 1,019 usable addresses per node subnet in VPC CNI mode,⁴ supporting several large compute nodes without running out of pod IPs.

Working with /31 and /32 edge cases

The standard formula 2^(32−n) − 2 breaks at two prefix lengths. A /32 identifies exactly one host address: the network and broadcast addresses are the same address, so subtracting 2 would give −1, which is meaningless. A /31 provides two addresses with no network or broadcast distinction : RFC 3021 explicitly allows both addresses for point-to-point links.⁵ Building on this, routers from Cisco, Juniper, and Linux all support /31 links for WAN connections, saving addresses when every /30 wastes 50% of its space to broadcast reservations. For loopback interfaces on Cisco IOS, use /32 to represent a single router ID without advertising a broader network in OSPF or BGP.

Planning host counts for Kubernetes and container runtimes

Container runtimes consume IP addresses faster than traditional VM workloads. Docker assigns one IP per container on the default bridge network, so a /24 bridge subnet exhausts after roughly 250 containers. Kubernetes with VPC CNI (used in EKS and GKE) assigns one VPC IP per pod, meaning a node with 110 pod capacity needs at least 110 IPs plus the node address. A /24 in AWS provides 251 usable addresses after the provider's 5 reservations, which accommodates two nodes at full density : but leaves no room for system pods or daemon sets.

Pre-allocating CIDRs for cluster growth

Before provisioning an EKS node group, calculate the maximum node count multiplied by per-node pod density to determine the minimum subnet size. For 20 nodes at 110 pods each, 2,200 pod IPs plus 20 node IPs require a /21 (2,046 usable in AWS). Using a /22 (1,019 usable) forces a subnet split across multiple Availability Zones, which complicates the Terraform module that manages node group placement. CapyToolkit's subnet calculator confirms each candidate CIDR's usable count before you commit it to your infrastructure-as-code configuration.

Host count arithmetic in network verification scripts

Automated verification scripts that assert expected host counts catch misconfigured subnets before they reach production. A script that reads every CIDR from a Terraform plan output and validates that the usable count exceeds the declared instance count prevents deployment failures in autoscaling groups. Python's ipaddress module makes this trivial: IPv4Network('10.0.0.0/22').num_addresses returns 1024,⁶ and subtracting 2 (or 5 for cloud) gives the usable count. Building on this, tying the check to a CI pipeline gate means any subnet change that reduces available addresses below a threshold triggers a pull request comment in GitHub or GitLab.

Storing prefix-to-count mappings in application config

Hardcoding host count lookups in application configuration avoids repeated runtime calculation. A JSON map from prefix length to usable host count : for example {"/24": 254, "/25": 126, "/26": 62, "/27": 30, "/28": 14, "/29": 6, "/30": 2} : serves as a fast reference for validation logic. Include a cloud-specific variant that subtracts 5 instead of 2. The calculator generates these mappings on demand, so you can export the exact reference table your application needs for its target deployment environment.

Python's ipaddress module offers an alternative to a static lookup table: calling len(list(IPv4Network('10.0.0.0/24').hosts())) or subtracting from num_addresses returns the usable count directly, and hosts() already applies the /31 exception automatically, including both addresses instead of returning zero. For cloud-adjusted counts, subtracting the provider's reservation from num_addresses avoids maintaining two separate tables for standard and cloud math.

Try in the tool