| # | Subnet Address | Range of Addresses | Hosts | Split / Join |
|---|---|---|---|---|
| {{ row.id }} | {{ row.cidr }} | {{ row.first }} – {{ row.last }} | {{ row.usable }} |
|
| Field | Value | Copy |
|---|---|---|
| {{ row.key }} | {{ row.value }} |
| ID | Subnet | CIDR | First usable | Last usable | Usable hosts | Copy |
|---|---|---|---|---|---|---|
| {{ subnet.id }} | {{ subnet.network }} | {{ subnet.cidr }} | {{ subnet.first }} | {{ subnet.last }} | {{ subnet.usable }} |
IPv4 subnetting divides one 32-bit address block into smaller blocks that can be routed, filtered, assigned, and documented with clear boundaries. That matters whenever one parent range has to serve several jobs at once, such as separate VLANs, infrastructure segments, lab networks, or point-to-point links.
A subnet plan is really a boundary plan. The useful questions are where the block begins, where it ends, how much host space each child range keeps, and whether the split still leaves clean room for growth. Once those answers are visible, prefix length stops feeling like abstract slash notation and starts reading like an address-allocation map.
That visibility is most useful when the starting address truly represents the network you mean to allocate. A real network base expresses the block cleanly. A host address sitting somewhere inside the block does not. The arithmetic can still be derived from that host address, but the final plan is harder to read and easier to miscommunicate.
The limit is practical rather than mathematical. Subnet planning can show valid ranges and likely capacity, but it cannot prove that routers, firewalls, DHCP scopes, or interface settings are already using those ranges correctly in the live environment.
IPv4 uses 32 bits. A prefix length tells you how many leading bits belong to the network portion, while the remaining bits belong to the host portion. The matching netmask keeps those network bits at 1 and clears the host bits to 0. The wildcard mask is the inverse pattern, which is why it is useful anywhere rules are written as bits that must match versus bits that may vary.
Once the prefix is fixed, the network address is found by masking the original address, and the broadcast address is found by setting every host bit to one. Address count follows powers of two: every added prefix bit halves the block. That is why a /24 becomes two /25 ranges, four /26 ranges, eight /27 ranges, and so on. Conventional usable-host counts subtract the network and broadcast addresses for prefixes through /30.
Two edge cases matter enough to read separately. RFC 3021 allows /31 prefixes on point-to-point IPv4 links by treating both remaining addresses as host addresses, so the usual network-versus-broadcast shortcut no longer applies there. A /32 leaves only one address, which is why it behaves like a single host or route target rather than a multi-host subnet.
Formula Core
A is the entered IPv4 address, M is the prefix mask, N is the network address, B is the broadcast address, and p is the prefix length.
| Prefix | Total addresses | Usable hosts | Planning meaning |
|---|---|---|---|
/24 |
256 | 254 | A common parent block for one midsize LAN or for several later splits. |
/25 |
128 | 126 | The first equal split of a /24, useful when one side still needs substantial growth room. |
/26 |
64 | 62 | A smaller branch cut that often fits servers, voice, IoT, or lab segments. |
/30 |
4 | 2 | The last conventional multi-host prefix before point-to-point special handling takes over. |
/31 |
2 | 2 | A two-ended link under RFC 3021, where both addresses are treated as hosts. |
/32 |
1 | 1 | A single-address route or host target rather than a shareable LAN subnet. |
Binary subdivision also explains joining. Two adjacent child blocks can recombine only when they are sibling halves of the same parent and their combined size exactly matches that parent prefix. A /25 can therefore merge back into its neighboring /25 to restore a /24, while unrelated or non-adjacent leaves cannot be collapsed cleanly.
The cleanest first pass is to enter the network start of the block you actually control, then choose the parent prefix you are trying to subdivide. In a campus or branch-office plan, that usually means typing the base like 192.0.2.0 and picking the pool you were handed, not a random client address that merely lives inside it.
The split bar is best for exploring equal-size cuts before anything is copied into documentation. Click a leaf bar to halve just that range. Shift-click a leaf, or click a parent bar, when you want to collapse siblings back into the larger block. Because each move is one binary step, mixed layouts such as one /25 plus two /26 blocks are easy to test without rebuilding the whole plan.
Subnet Summary when you need the parent network, netmask, wildcard, broadcast, first and last host fields, and overall host budget in one place.CSV Preview when the leaf rows are going into a spreadsheet, change ticket, or subnet review document.JSON when another checklist or script needs the current leaf set as structured records instead of a table.The most important trust check is alignment. If you type 10.0.0.5/24, the summary still identifies the parent network as 10.0.0.0/24, but the first leaf row begins at 10.0.0.5/24. That mismatch tells you the plan is anchored to a host address instead of the true network start, so fix the base before you export or share the result.
Capacity is the next thing to slow down on. Do not compare usable hosts only against today's device count. Leave room for management ports, printers, phones, temporary devices, and expected growth, then export only the row set you would be comfortable turning into VLAN, ACL, or DHCP documentation.
Start with the parent block, then refine only the leaves that need smaller ranges.
CIDR / prefix length.Subnet Overview first to confirm the network, netmask, wildcard, and usable-host total match the block you expected.Split / Join bar to split that leaf into two equal children.CSV Preview or JSON once the visible leaf rows match the allocation you want to hand off.The result area has two jobs. The summary identifies the parent prefix. The table beneath it lists the active leaf allocation after every split or join. Read both together before you treat the plan as final.
Usable hosts < required endpoints + reserve for any leaf row, that branch has been split too far for the intended workload.First host and Last host show N/A, you are looking at a /31 or /32 case and should read the row as a link or single-address route, not as a normal LAN segment.False confidence usually comes from confusing a mathematically valid range with a deployment-ready plan. A clean prefix still needs external checks against router summaries, DHCP exclusions, firewall objects, and naming conventions before it is safe to implement.
Enter 192.0.2.0/24. The summary reports network 192.0.2.0, netmask 255.255.255.0, broadcast 192.0.2.255, first host 192.0.2.1, last host 192.0.2.254, and 254 usable hosts. That is a clear starting point when one office or one parent VLAN still owns the whole range.
/24 into a mixed layoutStart with 198.51.100.0/24. Split once and the visible leaves become 198.51.100.0/25 and 198.51.100.128/25, each with 126 usable hosts. Split only the upper half again and the final layout becomes one /25 plus 198.51.100.128/26 and 198.51.100.192/26, each of those smaller leaves carrying 62 usable hosts. That is a typical pattern when users need the larger share and infrastructure or voice only needs smaller blocks.
Enter 203.0.113.8/31. The summary shows two usable hosts, while the first and last host fields switch to N/A. That is not an error. It reflects the special two-address link interpretation described in RFC 3021. A similar test with 203.0.113.9/32 reduces the block to one address, which is useful for a host route but not for a shared subnet.
Enter 198.51.100.37/24 and the summary still masks the parent network to 198.51.100.0/24. The leaf row, however, starts at 198.51.100.37/24 and shows the usable range from 198.51.100.38 to 198.51.100.254. That is the signal to stop, go back to the real network base, and rerun the plan before anyone mistakes a host address for the actual subnet start.
No. The inputs, masks, and split logic here are all based on 32-bit IPv4 addresses and IPv4-style prefix lengths.
You can enter any syntactically valid IPv4 address, but planning is clearest when that address is the real network base. If the summary shows one parent network and the first leaf row starts at a different address, you anchored the plan to a host address rather than the subnet boundary.
/31 show two usable addresses but no first or last host?A /31 is treated as a two-ended point-to-point link, so both addresses are usable endpoints under RFC 3021. The usual first-host and last-host labels stop being helpful in that case, which is why those fields are shown as not applicable.
It builds layouts through repeated halving and rejoining of adjacent sibling blocks. That means every visible leaf is still a valid power-of-two child of the original parent block, even when the final plan mixes larger and smaller leaves.
Yes. The address math, split layout, and exports are generated in the browser session. The practical caution is sharing: copied links or embed code can include the current IP, prefix, and split layout when query parameters are included.
/31