The cost of a sloppy subnet plan is paid years later, not on the day you deploy. Once a VPC is live, every tenant, every peering, every transit gateway depends on the allocation you committed to. The shortcut most teams take — eyeballing a /16 and “we’ll just chunk it into /24s” — works for one or two environments and falls apart the moment a fourth account, a second region, or a new partner needs a block that doesn’t overlap. The PortJar Subnet Splitter exists so you can stop estimating and start listing the actual children of a parent block, in order, with their broadcast and host ranges spelled out.
What the tool does
You give it a parent CIDR — 10.0.0.0/16, 172.20.0.0/20, 192.168.0.0/22 — and a new prefix length longer than the parent. It returns every resulting child subnet, in order, with the network address, broadcast address, and usable host range for each. The math runs entirely in the browser. Output is capped at 256 subnets so the page doesn’t melt under a /8 split into /24s; that limit is enough for almost every real plan and forces you to think twice before listing more.
Two common shapes: split 10.0.0.0/16 into /24s and you get 256 rows starting at 10.0.0.0/24 and ending at 10.0.255.0/24. Split 10.42.0.0/20 into /26s and you get 64 rows, each with 62 usable hosts. The output sits in a copyable table — easy to paste into a planning doc, a Terraform tfvars file, or a vendor handoff.
How to use it
Open portjar.com/tools/subnet-calculator, paste the parent CIDR, choose the new prefix length, and read the list. There is no need to compute how many subnets the split will produce — the tool tells you. If you ask for a split that would generate more than 256 rows, it caps the output and tells you the cap was hit; that usually means you wanted a less aggressive split.
If you only want to see, say, the third child of a /16 split into /20s, the tool’s row index makes that trivial — count to row three, take its CIDR, done.
When you’d reach for it
- Multi-AZ VPC layout. You have a
/16for a region and need three /24s per AZ across three AZs. Splitting at /24 gives you 256 rows; the first nine are your AZ subnets, the rest is future capacity. - Multi-tenant allocations. A SaaS plane needs a clean
/24per tenant inside a/16. Splitting at /24 lists every block, so you can hand contiguous ranges to onboarding without overlapping the next tenant’s slot. - Peering plans. A partner wants a /28 for a transit link. Splitting your /24 reservation at /28 shows all 16 candidate blocks; pick the one furthest from anything in use to leave room for growth on both sides.
- Migration from a single big block to per-environment blocks. Production, staging, and dev all live in one /22 and you need to give each its own /24. The split tells you exactly which four /24s exist and what the boundaries are.
- Audit work. A network diagram shows children of a /20 but you suspect they overlap. Listing all valid /24 children and comparing against the diagram surfaces the overlap in seconds.
What to make of the output
Every row in the result is internally consistent — network, broadcast, and host range all reflect the same prefix length you chose — so if you copy a single child you can trust it without re-validation. The order is strictly ascending; row one is the lowest block, the last row is the highest.
If the result is empty, the prefix length you asked for is shorter than (or equal to) the parent — that’s not a split, that’s a no-op. If the result is exactly one row, you asked for the same prefix as the parent; same problem. Both cases mean the form needs adjusting, not that the tool failed.
The 256-row cap is a sanity check, not a bug. A /16 split into /30s would produce 16,384 rows, which is rarely what anyone actually wants to read. If you genuinely need the full list, do the split in two passes — half the parent first, then split each half — or stop and ask whether you actually need every block or just the next few you intend to allocate.
For environments where the subnet plan needs to stay consistent across regions, accounts, and tenants, Stack Harbor maintains the canonical allocation map as part of environment management.