| Network | Usable Min | Usable Max | Broadcast | Copy |
|---|---|---|---|---|
| {{ s.networkAddress }} | {{ s.usableMin }} | {{ s.usableMax }} | {{ s.broadcastAddress }} |
| # | Network | CIDR | Total IPs | Usable IPs | Pool Share | Copy |
|---|---|---|---|---|---|---|
| {{ row.index }} | {{ row.networkAddress }} | {{ row.cidr }} | {{ row.blockSize.toLocaleString() }} | {{ row.usableCount.toLocaleString() }} | {{ row.sharePercent }}% |
An IPv4 subnet split is the act of taking one address block and cutting it into smaller, evenly sized networks that can be routed, documented, and assigned to different parts of an environment. The stakes are practical: if each child block is too large, addresses sit idle, and if each one is too small, the design runs out of host room before the rollout is finished.
This calculator is built for that equal-slice planning problem. It accepts any IPv4 address that belongs to the parent range, normalizes it to the correct network base, and then shows the child network address, usable host span, broadcast boundary, and aggregate capacity loss caused by repeating the split.
That makes it useful in the stage where an addressing plan is becoming concrete but has not yet been pushed into DHCP scopes, router interfaces, firewall objects, or inventory sheets. A common example is taking one office /24 and deciding whether it should become four /26 VLANs, eight /27 segments, or something shallower that preserves host headroom.
The package also gives the split more than one reading surface. In addition to the child-network table, it builds a capacity ledger, a stacked usable-versus-reserved chart, and a JSON payload that mirrors the calculation state. Those extra views matter because subnetting mistakes are often not arithmetic mistakes at all. They are planning mistakes hidden inside repeated edge reservations and copied ranges.
What this does not mean is variable-length subnet design. The package uses one target prefix for every child block, so it is strong when you want equal slices and weak when you need differently sized networks from the same parent. The result is therefore a boundary worksheet, not a full IP address management system and not a deployment validator.
The quickest way to use the page is to start from the parent network question rather than the host question. Enter an address you know sits inside the parent block, then set the current prefix and the deeper target prefix. The summary immediately tells you how many child networks the split creates and how many usable addresses remain after every child block pays its own network-and-broadcast overhead.
The first reading checkpoint is the summary bar. Broadcast confirms the upper edge of the parent block, Child Networks confirms the count produced by the new prefix length, and Usable IPs tells you how much assignable space is left after the split. If that usable total falls faster than expected, the next place to look is Capacity Ledger, where the repeated reserved-address cost becomes obvious row by row.
The table views answer slightly different questions. Subnet Slices is the most useful tab when you want exact boundaries to copy into a worksheet or a ticket. Capacity Ledger is the planning tab because it shows raw block size, usable hosts, reserved hosts, and each child block's share of the usable pool. Host Capacity Chart is a quicker visual comparison when you want to see whether the split is reasonable before reading every line.
There are two common misreads to avoid. First, the page accepts a host address inside the parent block, but the tool always normalizes that entry to the correct parent network before it calculates anything. Second, identical pool share does not mean identical operational demand. Equal subnets are mathematically equal, not necessarily equally suitable for printers, users, cameras, wireless clients, or transit links.
If the design looks plausible, verify one representative child against the intended VLAN, gateway convention, or DHCP scope before you trust the rest. Equal subdivision tends to repeat correctly once the first row is right. That makes the first row the most important row in the whole result.
IPv4 addresses are 32-bit numbers. The package converts the dotted-decimal input into an unsigned integer, derives the current-prefix mask, and applies that mask to recover the canonical parent network. It then inverts the mask to find the parent broadcast boundary. This is why you can enter a live host such as 192.168.50.37 and still get a parent summary anchored to the correct network base.
The split itself is pure prefix arithmetic. If the target prefix is deeper than the current prefix by d bits, the page creates 2^d child networks. Each child network contains 2^(32 - targetPrefix) total addresses. Because the visible workflow stops at /30, every rendered child block uses the conventional two-address reservation model: one address for the network identifier and one for the directed broadcast edge.
That reservation model is what the tool makes easiest to see. The parent address span never changes, but the overhead grows every time you split more deeply because the same two reserved addresses are repeated in every child block. A shallow split preserves larger assignable pools. A deep split may look tidy on paper while consuming a surprising fraction of the parent range in repeated edge space.
The chart and JSON views are driven from the same child-block array used by the tables. The chart plots one stacked bar per child prefix with separate usable and reserved counts. The JSON view mirrors the inputs, normalized summary, child rows, capacity ledger, chart series, and any validation errors, so the same calculation can be exported into another workflow without retyping the boundaries by hand.
| Symbol | Meaning in this package | Where it shows up |
|---|---|---|
A |
Entered IPv4 address converted to a 32-bit integer | Parent normalization step |
M |
Mask implied by Current CIDR |
Parent network and broadcast recovery |
N |
Canonical parent network address | Base-Network Summary |
B |
Parent broadcast address | Summary badge and range checking |
K |
Equal child-network count created by the deeper prefix | Child Networks badge |
S |
Total addresses in each child block | Total IPs in Capacity Ledger |
U |
Usable host addresses in each child block | Usable IPs rows and summary total |
| Package rule | Observed behavior | Practical consequence |
|---|---|---|
| Parent normalization | Any host inside the parent block is masked back to the parent network base. | You do not need to know the exact network address before using the tool. |
| Target-prefix validation | Target CIDR must be deeper than Current CIDR and no larger than /30. |
Every rendered child block has a conventional host span with network and broadcast edges. |
| Equal-size split model | All child rows use the same target prefix and block size. | The package does not perform variable-length subnet masking. |
| Repeated reservation model | Each child block loses two addresses to edge reservation. | Deeper splits reduce total assignable space faster than many planners expect. |
Current CIDR, then choose a deeper prefix in Target CIDR.Base-Network Summary first to confirm the normalized parent network, parent broadcast, child count, and total usable host pool.Subnet Slices and verify one representative child row, including Network, Usable Min, Usable Max, and Broadcast.Capacity Ledger to compare raw size, usable hosts, reserved addresses, and pool share across the repeated child blocks.Host Capacity Chart when you want a faster visual read of usable-versus-reserved balance.The most important distinction in the output is between address span and assignable span. Network and Broadcast define the edges of each child block. Usable Min and Usable Max define the addresses that can actually be handed to hosts under the tool's current model. If those usable boundaries are tighter than expected, the split may be mathematically correct but operationally too aggressive.
Capacity Ledger is where overhead stops being abstract. A shallow split may leave most of the parent pool available to hosts, while a deeper split can consume a noticeable portion of the same parent range in repeated edge reservations. That does not mean the deeper split is wrong. It means the design is paying for segmentation with usable space.
The chart should be read as a shape check, not as a recommendation engine. Because every child block is the same size, the bars will match. What matters is the proportion between usable and reserved portions. If the reserved segment begins to feel large relative to the usable segment, it is often a sign that the design has been cut deeper than the deployment really needs.
The final trust check is still external to the tool. Confirm one child block against the interface plan, DHCP lease scope, or firewall object sheet you intend to use. If the first verified child aligns with the operational plan, the remaining children are usually safe to treat as repeated arithmetic rather than fresh analysis.
Suppose an address ticket mentions 192.168.20.41, but the parent network has not been written down. Set Current CIDR to /24 and Target CIDR to /26. The summary resolves the parent to 192.168.20.0/24, shows four child networks, and reports a combined usable total of 248 hosts.
The first child row runs from 192.168.20.0/26 with usable hosts 192.168.20.1 through 192.168.20.62. That leaves a clean four-VLAN plan with equal host pools and predictable boundaries for downstream documentation.
Take 10.40.8.9 with parent /28 and split it to /30. The child count rises to four, but each row now carries only two usable host addresses because the block size is four and two addresses are reserved by the model.
The arithmetic is correct, but the ledger shows why this can be a poor choice for user-facing segments. Half of each child block becomes overhead. That may still be acceptable for tightly scoped link networks or paired appliances, but it is a warning sign for ordinary LANs.
Enter 172.16.12.14 with parent /24 and try to set the target to /24 or /31. The tool refuses the request because the target must be deeper than the current prefix and the visible workflow stops at /30.
That validation matters because it prevents two common worksheet errors: treating an unsplit parent as a successful subdivision and assuming the tool will model special point-to-point conventions that it does not actually expose in its host-range outputs.
No. The package masks any entered host address back to the correct parent network before it builds the split, so a live host address inside the range is enough to begin.
Because every child block repeats the same edge reservation. The more child networks you create, the more times the tool subtracts those reserved addresses from the same parent pool.
No. The package is designed for equal subdivision only. If one department needs a much larger range than another, this tool can illustrate the equal-size alternative but it cannot build a variable-length plan.
RFC 3021 defines a special two-address interpretation for point-to-point links, but this page is built around child rows that expose conventional host spans and broadcast boundaries. The UI therefore stops at /30.
No. It validates IPv4 structure and equal-split arithmetic, but it does not judge whether the chosen range is private, special-purpose, already allocated elsewhere, or acceptable to a specific routing or provider policy.
/24 or /27 that states how many leading bits belong to the network portion.