| # | 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 is the practice of carving one 32-bit address block into smaller, predictable ranges. It matters because routing, firewall rules, VLAN plans, and inventory documents all depend on knowing exactly where a block starts, where it ends, and how many usable endpoints fit inside it. This page turns that planning exercise into a visible split map instead of a notebook full of prefix math.
The package centers on one anchored IPv4 block. You enter an address and a prefix length, then the summary shows the network identity, netmask, wildcard mask, broadcast address, first and last usable host, and usable-host count. Below that, a color bar and allocation table let you split the current block into equal child subnets, join sibling ranges back together, and export the resulting plan as CSV, JSON, or DOCX.
That is useful when a network has to be explained as well as calculated. A /24 that serves one flat office today may need to become two /25 ranges for separate floors, or one /25 plus two /26 segments for servers and infrastructure. The page keeps the arithmetic and the visible layout tied together, so you can see how each click changes address coverage and host capacity.
The tool is most trustworthy when the address you enter is the actual starting address of the block you want to plan. If you model 10.0.0.0/24, the rows and split bars line up cleanly with textbook subnet boundaries. That makes the page better for allocation reviews, migration discussions, and documentation drafts than for probing a random host address inside an unknown network.
The caution is scope. This is an IPv4 planning aid, not a reachability test, route validator, or DHCP audit. It can tell you how many addresses a split contains and where the ranges begin and end, but it cannot prove that an upstream router, switch, or host configuration is using those ranges correctly.
Start with the block you actually intend to allocate, not merely a host that happens to live inside it. If you are planning a branch LAN, enter the network start such as 192.168.40.0 and then choose the prefix you have available. The summary badges immediately tell you the netmask, wildcard, and usable-host budget for that starting point.
Use the split bar when you are comparing allocation options, not just checking a single CIDR range. A normal click on a leaf range halves it into two equal children. A Shift-click, or a click on a parent segment in the visual stack, joins adjacent siblings back into their larger parent. That makes it easy to explore binary subdivision patterns without re-entering the base block each time.
The most common decision mistake is sizing only for raw device count. A team of 40 endpoints rarely stays at 40 once printers, phones, management interfaces, reserve growth, and temporary devices are added. When two split options both fit the current count, the better choice is usually the one that leaves cleaner room for growth without wasting an entire larger block.
Another easy mistake is forgetting special prefixes. A /31 behaves differently from an ordinary multi-host LAN because it is commonly used as a two-endpoint link, and a /32 is a single-address route. The page reflects those edge cases in the host counts and host-range fields, so read them before assuming every subnet reserves a separate network and broadcast slot in the same way.
IPv4 addresses are 32-bit values written in dotted-decimal form. CIDR, short for Classless Inter-Domain Routing, expresses how many of those 32 bits belong to the prefix. Once the prefix length is known, the page derives the netmask, wildcard mask, network address, broadcast address, and host counts directly from bitwise relationships rather than from a lookup table.
The summary view follows the usual network arithmetic. For prefix length p, the mask keeps the first p bits and clears the rest. The network address is the entered value masked by that prefix, and the broadcast address fills the host portion with ones. For prefixes up to /30, usable hosts exclude the network and broadcast addresses. For /31, the package reports two usable addresses, and for /32 it reports one address with first and last host shown as not applicable.
The split planner uses binary subdivision. Each split replaces one leaf subnet with two equal halves whose prefix length is one bit longer. Repeated clicks let you build mixed final layouts such as one /25 beside two /26 ranges, even though each individual operation is only a halving step. Joins work in the opposite direction and succeed only when the visible leaves form a contiguous sibling set that exactly covers the larger parent range.
The page also keeps the current split pattern in the URL state as a compact list of leaf prefixes. That is useful for bookmarking or revisiting a draft layout later, because the visual allocation can be reconstructed from the saved prefix sequence without storing server-side session data. All visible exports are generated from the same current leaf list, so the table, JSON payload, and DOCX table stay in sync.
| Output | Meaning | How it is used here |
|---|---|---|
| Network | Base prefix after masking | Displayed in the summary headline and export subtitles. |
| Netmask | 32-bit mask in dotted-decimal form | Shown as a quick check for interface or ACL planning. |
| Wildcard | Inverse of the mask | Useful when translating the range into ACL-style patterns. |
| Broadcast | Top address in the covered block | Helps confirm the full span of the current prefix. |
| First / last host | Usable host boundaries when they exist | Shown as N/A for /31 and /32. |
| Leaf subnet rows | Current allocation after all splits and joins | Copied and exported in CSV, JSON, and DOCX formats. |
No separate backend path is defined for calculations or exports in this package. The parsing, bit math, split tree, clipboard actions, and file downloads are performed in the browser session, which is why the same inputs always regenerate the same allocation view until you change the entered address, prefix, or split state.
The summary box answers the question “What is this base prefix?” The allocation table answers the question “What have I turned it into?” Those are related but not identical views, especially after repeated splits. Treat the summary as the parent-block identity and the rows as the active plan you would hand to another person.
N/A, you are in a /31 or /32 case and should read the address semantics accordingly.Exports are mirrors of the current plan, not separate calculations. If the table is right, the CSV, JSON, and DOCX versions describe the same leaf set in different formats. That makes the table the best place to perform a final visual sanity check before sharing the result.
Suppose you start with 10.0.0.0/24. The page reports a netmask of 255.255.255.0, a broadcast address of 10.0.0.255, and 254 usable hosts. That is the right fit for one medium flat LAN, but it may be too broad if the office actually needs separate staff, voice, and infrastructure segments.
Split 10.0.0.0/24 once and you get two /25 ranges with 126 usable hosts each. Split only the upper half again and the final rows become one /25 plus two /26 ranges. That is a practical way to reserve a larger user segment while carving smaller spaces for servers or network equipment without discarding the rest of the block.
Enter 198.51.100.0/31 and the tool shows two usable addresses, which matches the common two-endpoint interpretation for point-to-point links. Enter 198.51.100.7/32 and the page reduces the block to one address. In both cases the special host semantics matter more than the usual “network plus broadcast plus hosts” mental shortcut.
No. The parser, mask logic, and range displays are all specific to 32-bit IPv4 addresses.
You can enter any syntactically valid IPv4 address, but the planning view is cleanest when that address is the actual start of the block you intend to subdivide.
A join succeeds only when adjacent visible leaves form a proper sibling pair or a parent branch that exactly covers the larger range.
Not directly. The planner works by repeated halving and rejoining, so every leaf comes from binary subdivision of the original block.
For /31 and /32, the package treats host semantics differently and shows those fields as not applicable.
No remote processing path is defined for this package. The calculations and exports are generated in the browser session.
/31, and /32 cases.