Subnet Overview
{{ summary.network }} / {{ summary.prefix }}
{{ summary.netmask }} Netmask {{ summary.wildcard }} Wildcard {{ summary.usableHosts }} Usable Hosts
# Subnet Address Range of Addresses Hosts Split / Join
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 }}

        
:

Introduction:

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.

Diagram showing a 192.0.2.0/24 block split into two /25 ranges, with the upper /25 split again into two /26 ranges.

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.

Technical Details:

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

N = AM B = N¬M Atotal = 232p Husable = if p30, Atotal2; if p=31, 2; if p=32, 1

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.

IPv4 prefix checkpoints that affect subnet planning
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.

Everyday Use & Decision Guide:

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.

  • Use Subnet Summary when you need the parent network, netmask, wildcard, broadcast, first and last host fields, and overall host budget in one place.
  • Use CSV Preview when the leaf rows are going into a spreadsheet, change ticket, or subnet review document.
  • Use 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.

Step-by-Step Guide:

Start with the parent block, then refine only the leaves that need smaller ranges.

  1. Enter the IPv4 network base for the block you want to plan, then choose the parent value in CIDR / prefix length.
  2. Read Subnet Overview first to confirm the network, netmask, wildcard, and usable-host total match the block you expected.
  3. Click a colored leaf in the Split / Join bar to split that leaf into two equal children.
  4. Use Shift-click on a leaf, or click a parent segment, when you want to join sibling blocks back into the larger parent.
  5. Open CSV Preview or JSON once the visible leaf rows match the allocation you want to hand off.
  6. Before copying or exporting, make sure the first leaf row starts at the intended network base and that every leaf has enough usable-host room for the real endpoint count plus reserve.

Interpreting Results:

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.

  • If the first leaf row CIDR matches the parent network and prefix, the plan is anchored cleanly.
  • If the first leaf row starts later than the summary network, re-enter the network base. The current layout is centered on a host address rather than a true subnet boundary.
  • If Usable hosts < required endpoints + reserve for any leaf row, that branch has been split too far for the intended workload.
  • If 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.
  • If the table looks right, the CSV, JSON, and DOCX exports are describing that same current leaf set rather than a separate recalculation.

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.

Worked Examples:

One clean parent block

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.

Turning one /24 into a mixed layout

Start 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.

Reading a point-to-point edge case

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.

Troubleshooting a misaligned starting address

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.

FAQ:

Does it support IPv6 subnetting?

No. The inputs, masks, and split logic here are all based on 32-bit IPv4 addresses and IPv4-style prefix lengths.

Can I start from any host address inside a subnet?

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.

Why does /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.

Can it build arbitrary custom subnet sizes?

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.

Do the calculations stay local?

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.

Glossary:

CIDR prefix
The slash-length that says how many leading IPv4 bits belong to the network portion of the block.
Netmask
The dotted-decimal mask derived from the prefix, with network bits set to one and host bits set to zero.
Wildcard mask
The inverse of the netmask, often used in rule sets that describe which bits may vary.
Broadcast address
The highest address in the covered prefix, formed by setting every host bit to one.
Leaf subnet
One currently visible end block after all active splits and joins.
Sibling halves
Two adjacent child blocks of equal size that can merge back into the same parent prefix.
Point-to-point /31
A two-address IPv4 link where both addresses are interpreted as hosts instead of reserving separate network and broadcast slots.

References: