Subnet / CIDR Calculator
Enter an IPv4 address with a CIDR prefix or netmask to get network range, host count, and broadcast address — all computed in your browser.
Worked examples
Reading a /24, a /16, and a /10
10.0.0.0/24
| Netmask | 255.255.255.0 | Wildcard mask | 0.0.0.255 |
| Network address | 10.0.0.0 | Broadcast address | 10.0.0.255 |
| Usable hosts | 254 | ||
The workhorse LAN subnet: 256 total addresses, 254 usable. Typical VLAN size for an office or a small server segment.
192.168.0.0/16
| Netmask | 255.255.0.0 | Wildcard mask | 0.0.255.255 |
| Network address | 192.168.0.0 | Broadcast address | 192.168.255.255 |
| Usable hosts | 65,534 | ||
A full RFC 1918 class-B block: 65,536 total addresses. Usually the VPC or campus allocation that gets carved into /24s.
10.0.0.0/10
| Netmask | 255.192.0.0 | Wildcard mask | 0.63.255.255 |
| Network address | 10.0.0.0 | Broadcast address | 10.63.255.255 |
| Usable hosts | 4,194,302 | ||
A /10 spans four class-B blocks (10.0.x.x through 10.63.x.x). The mask stops mid-octet — 255.192 — which is where binary math pays off.
The pattern behind all three: usable hosts = 2^(32 − prefix) − 2, the network address is the block's first address, the broadcast is its last, and the wildcard mask is the netmask with every bit flipped. Paste any of the three CIDRs above into the calculator to see the binary breakdown.
About this tool
Subnet / CIDR Calculator
Enter an IPv4 address with a CIDR prefix (10.0.0.0/24) or a netmask (10.0.0.0 255.255.255.0) and get the full picture of that network: network and broadcast addresses, the usable host range, wildcard mask, IP address class, and whether the range is RFC 1918 private space.
The splitter takes the same network and divides it into equal-sized subnets at a longer prefix — useful for planning VLANs, carving up a /24 into /26s for separate segments, or checking how many /30 point-to-point links fit inside a larger block.
Both notations mean the same thing, and the calculator converts in either direction: a CIDR prefix like /24 and its dotted network mask 255.255.255.0 are two spellings of one value. Paste 10.0.0.0/24 or 10.0.0.0 255.255.255.0 — whichever form your source uses — and you get the other one back alongside the network and broadcast addresses.
The result panel also shows the binary view: the address and the mask rendered as four binary octets, one bit per column. That binary alignment is what subnet math actually is — the network address is where the host bits go to zero, the broadcast is where they go to one, and a /10 looks confusing in dotted-decimal (255.192.0.0) but obvious in binary. If you've ever wanted a visual subnet calculator that shows the bits rather than hides them, this is that view.
Subnetting gets its second life in the cloud. Every VPC, VNet, and virtual network is just CIDR blocks and the same arithmetic: pick a supernet, carve it into subnets big enough for the workload plus reserved addresses, and keep the blocks non-overlapping so peering and VPN routes stay possible. See the VPC section below for the cloud-specific constraints.
All math runs in your browser with plain integer arithmetic on the address — nothing is looked up or sent anywhere.
When to use it
Plan a VLAN layout
Enter your allocated block and split it into the subnet size each VLAN needs, then read off each segment's usable range.
Check if two hosts are on the same subnet
Compute the network address for each host's IP/mask — if they match, the hosts share a broadcast domain.
Size a subnet for a host count
Usable hosts = 2^(32 − prefix) − 2. Work backwards from a required host count to the smallest prefix that fits.
Plan a VPC's address space
Start from the supernet you'll allocate to the cloud account, split it per environment (prod, staging, peered networks), and check the usable range after the provider's reserved addresses.
Questions
How do I convert CIDR to a subnet mask (and back)?
Type the network with either notation — 192.168.1.0/24 or 192.168.1.0 255.255.255.0 — and the calculator shows both, plus the wildcard mask. The conversion is bit counting: /24 means 24 one-bits, which is 255.255.255.0; a /10 means 10 one-bits, which is 255.192.0.0. To go the other way — calculate a CIDR prefix from a subnet mask, or convert a network mask to CIDR — count the leading one-bits of the mask: 255.255.248.0 has 21 of them, so it's /21. Enter the netmask form here and the prefix is computed for you.
What is a wildcard mask?
The inverse of the subnet mask: every bit flipped, so 255.255.255.0 becomes 0.0.0.255. Cisco ACLs and OSPF configurations use wildcards to express match ranges — 10.1.0.0 0.0.255.255 matches everything in 10.1.x.x. The result panel shows the wildcard mask for any input, so an IP calculator CIDR conversion here also gives you the ACL-ready form.
How many usable hosts does a subnet have, and where does the gateway fit?
Usable hosts = 2^(32 − prefix) − 2. The first address in the block is the network address and the last is the broadcast, and neither can be assigned to a host (/31 and /32 are special cases under RFC 3021). The gateway is just one of the usable addresses — by convention usually the first (10.0.0.0/24 → gateway 10.0.0.1) — and some cloud providers force it: AWS reserves the first four and last address of every subnet, Azure reserves five, so a cloud subnet always yields slightly fewer practical addresses than the raw formula.
Can I use this as a VPC CIDR calculator for AWS, GCP, or Azure?
Yes, with two caveats. The math is identical — a /24 in a VPC is the same /24 anywhere — but the providers impose bounds: AWS VPC CIDRs must fall between /16 and /28, subnets between /16 and /28, with up to five CIDR blocks per VPC; GCP and Azure have their own per-subnet size limits and reserved-address rules. Second, each cloud reserves a handful of addresses in every subnet (five on AWS and Azure), so subtract those from the usable count before sizing. This calculator does the CIDR arithmetic and the splitter does the carving; check your provider's current limits for the bounds, since they change.
How big should a cloud subnet be?
Size for what deploys into it, plus growth you won't be able to fix later — you generally can't shrink a subnet in place. A /24 (251 usable on AWS after reservations) is a comfortable default for a general workload subnet; a /27 or /28 is plenty for a database tier or a load-balancer subnet. Keep the aggregate VPC large enough (/16 is the common choice) that you can add subnets without repurposing the whole network.
What makes this different from a visual subnet calculator?
Visual subnet calculators draw the bit grid so you can see which bits are network and which are host. This tool gives you the same information numerically: the result panel shows the address and mask as four binary octets with the mask bits highlighted, plus network, broadcast, first/last host, wildcard, and class for every input. You get the visual insight — where the boundary bit falls — without the chart.
What input formats does this IP/CIDR calculator accept?
CIDR notation (10.0.0.0/24) or address-plus-netmask (10.0.0.0 255.255.255.0). Any valid IPv4 address works, including one that isn't the network address — 10.0.4.77/22 is normalized to its network 10.0.4.0/22. Masks must be contiguous (255.255.248.0 is valid; 255.0.255.0 is not), and prefixes range from /0 to /32.
How do I split a network into smaller subnets?
Enter the parent network and use the splitter below the input: give it the new, longer prefix and it lists every child subnet with its host range and broadcast address. Each +1 in prefix doubles the count — a /24 splits into 2 /25s, 4 /26s, 256 /30s. Splits beyond 256 child subnets are capped for display.
Why are usable hosts 2 less than total addresses?
The first address in a subnet is reserved as the network address and the last as the broadcast address, so neither is assignable to a host — except for /31 and /32, which have special-case (0 and non-network) host counts under RFC 3021.
Does this support IPv6?
No — this calculator is IPv4-only. IPv6 prefix math (/64 subnets, EUI-64) is a large enough topic to warrant its own tool.
Is my IP address sent anywhere?
No. All calculation happens client-side with integer bit math — nothing is uploaded or logged, and the tool works offline.
Related resources
Further reading
Cloud planning
Subnetting in the cloud: VPC CIDR planning
On-premises subnetting is flexible — resize a VLAN and move on. Cloud address space isn't: a VPC's CIDR blocks are fixed at creation (primary) or added carefully (secondary), and every subnet inside them competes for the same space. Overlap is permanent failure — two networks with overlapping CIDRs can't peer, attach over VPN, or share transit, and you'll only discover this when a second environment needs to connect. The discipline is the same everywhere: allocate a generous supernet per account or project, carve it into non-overlapping subnets with room to grow, and run the math before anything deploys.
AWS
A VPC takes its primary CIDR between /16 and /28, plus up to four secondary blocks. Subnets range /16 to /28. AWS reserves five addresses per subnet — the first four and the last — so a /24 gives you 251 usable, not 254. Region-level service quotas on IPs per subnet make over-tight subnets the classic planning mistake.
GCP
Subnets belong to regions, not zones, and each carries a primary range plus optional secondary ranges for alias IPs. Size primary ranges like AWS subnets, but remember secondary ranges consume address space separately — pods and services in GKE each want their own non-overlapping range, which is where most GCP address plans collide.
Azure
A VNet holds one or more address spaces; subnets carve them up. Azure reserves five addresses per subnet (the first four and the last) for DNS and gateway services — same practical haircut as AWS. Dedicated subnets are mandatory for some services (gateways, firewalls, private endpoints), so budget space for them explicitly.
The exact provider limits above shift over time — treat them as planning guidance and confirm against the current AWS, GCP, and Azure documentation before committing an address plan. The arithmetic itself doesn't change: whatever the bounds, this calculator and the splitter compute the same network, broadcast, and usable-host range your cloud console will enforce.