Visualize how a parent CIDR block is divided into subnets with allocation bars and utilization metrics.
Last verified: May 2026
Output will appear here...The visualizer parses the parent CIDR into a 32-bit integer range, then for each child subnet computes its start address, end address, and prefix mask. Subnets are sorted by start address and rendered as proportional blocks against the parent range, with overlap detection that flags any pair whose ranges intersect. Free space between subnets is rendered as gap blocks so unallocated capacity is visible at a glance.
Splitting a /16 into /24s on paper is straightforward; planning a real VPC where some subnets are /20 for workloads, others are /28 for VPN endpoints, and a chunk is reserved for future zones is where mistakes happen. The IPv4 Subnet Visualizer draws the allocation as proportional blocks so you can see at a glance which ranges are consumed, which are free, and how much of the parent CIDR is wasted by oversized subnets. It is the fastest way to sanity-check a subnet plan before pasting it into Terraform.
Your team has been told to design a VPC for a new region that will host three environments (dev, staging, prod), each spread across three availability zones, plus shared services for the VPN, transit gateway, and PrivateLink endpoints. You sketch a /16. You paste it into the visualizer with a proposed split: nine workload /20s plus a /22 for shared services. Immediately you see one of the staging /20s overlaps a prod /20 — an off-by-one in the third octet. Fix it in the planner, copy the corrected ranges into Terraform, ship.
Plan address space top-down: pick a /16 you can grow into, carve it into per-AZ /20s, then break each /20 into workload subnets. Skipping the per-AZ step leads to subnets scattered across zones and impossible to renumber later.
Leave at least 25% of the parent CIDR unallocated. New zones, future workloads, and emergency carve-outs always show up — and a VPC with no spare space forces you into peered or transit gateway workarounds that add cost and latency.
Every IPv4 subnet reserves a network address, broadcast address, and (on most cloud providers) two to three additional addresses for the implicit router, DHCP, and DNS. A /28 has 16 total addresses but only 11 usable on AWS, 11 on Azure, and 13 on GCP. The visualizer surfaces this so you do not allocate a /29 expecting 8 usable IPs and discover you have 3.
The tool accepts subnets down to /32. In practice, most cloud providers refuse subnets smaller than /28 (16 addresses); some refuse /30 or /29. AWS enforces /28 minimum on VPC subnets, GCP enforces /29, Azure enforces /29 for VNet subnets and /27 for some managed services like Application Gateway.
Was this tool helpful?
Disclaimer: This tool runs entirely in your browser. No data is sent to our servers. Always verify outputs before using them in production. AWS, Azure, and GCP are trademarks of their respective owners.