This calculator sorts your segments, rounds each one up to the nearest power of two, and slides every block into place without leaving a gap a person would have to spot by hand. None of that is hidden. The four sections below lay out exactly how the math works, walk a full seven-segment plan from a bare network address to a finished allocation table, list the edge cases most subnetting references skip over, and answer the questions this calculator gets asked most often — so you can check any result it gives you by hand, using the same rules it does.
Method
Every VLSM plan this calculator produces comes from the same four rules, applied in the same order, every time. There is no randomness and no manual adjustment behind the scenes — feed in the same base network and the same segment list twice, and the same allocation comes out both times. These are also the four steps the worked example below follows, segment by segment.
Sort by size
Segments are ordered largest host count first. Placing big blocks before small ones is what stops holes appearing that nothing can use.
Round up the prefix
Each segment needs hosts + 2 addresses (network and broadcast), rounded up to the next power of two. 60 hosts needs 62, so it takes a /26.
Align and advance
A subnet must start on a multiple of its own size. The cursor jumps forward to the next legal boundary, then moves on by one block.
Point-to-point links
Two-host segments are given a /31 per RFC 3021, where both addresses are usable.
Worked example
Here is a complete plan worked by hand, start to finish, using the same seven-segment campus network this site's homepage loads when you click Campus example: a base network of 172.16.0.0/22 — 1,024 addresses in total — split across a wifi segment, a student lab, a staff office, a library, a server room, and two router-to-router links. Every number below, including the final allocation table, matches exactly what the calculator itself prints for this input; nothing here is rounded differently or simplified for the page. Follow along with the same four steps 1.0 Method describes above.
| Segment name | Hosts |
|---|---|
| Lecture hall wifi | 450 |
| Student labs | 210 |
| Staff offices | 90 |
| Library kiosks | 25 |
| Servers | 12 |
| Core link A | 2 |
| Core link B | 2 |
STEP 1Sort by size
Sorted from the largest host count to the smallest, the seven segments come out in this order: Lecture hall wifi (450), Student labs (210), Staff offices (90), Library kiosks (25), Servers (12), then Core link A and Core link B, both asking for exactly 2 hosts. Core link A and Core link B tie on host count, so the sort leaves them in the order they were entered — Core link A first — rather than picking one arbitrarily.
STEP 2Round up the prefix
Each segment's host count plus 2 — for the network and broadcast addresses — gets rounded up to the next power of two, which sets the prefix. 450 hosts need 452 addresses, which rounds up to 512, a /23. The same arithmetic gives Student labs a /24, Staff offices a /25, Library kiosks a /27 and Servers a /28:
| Segment name | Hosts | Hosts + 2 | Next power of two | Prefix |
|---|---|---|---|---|
| Lecture hall wifi | 450 | 452 | 512 | /23 |
| Student labs | 210 | 212 | 256 | /24 |
| Staff offices | 90 | 92 | 128 | /25 |
| Library kiosks | 25 | 27 | 32 | /27 |
| Servers | 12 | 14 | 16 | /28 |
| Core link A | 2 | — | — | /31 |
| Core link B | 2 | — | — | /31 |
Core link A and Core link B skip this arithmetic entirely — a 2-host segment goes straight to a /31 under the RFC 3021 exception covered in STEP 4 below, instead of rounding 4 addresses up from hosts + 2.
STEP 3Align and advance
Starting at the base network's first address, 172.16.0.0, each block is placed at the next address that is a multiple of its own size, then the cursor advances past it. In this particular plan every block happens to land on a legal boundary immediately — the cursor never has to jump forward to skip a gap — so each row below is simply “place the block, then move the cursor on by exactly its size”:
| Segment name | Cursor before | Block placed | Cursor after |
|---|---|---|---|
| Lecture hall wifi | 172.16.0.0 | 172.16.0.0/23 | 172.16.2.0 |
| Student labs | 172.16.2.0 | 172.16.2.0/24 | 172.16.3.0 |
| Staff offices | 172.16.3.0 | 172.16.3.0/25 | 172.16.3.128 |
| Library kiosks | 172.16.3.128 | 172.16.3.128/27 | 172.16.3.160 |
| Servers | 172.16.3.160 | 172.16.3.160/28 | 172.16.3.176 |
| Core link A | 172.16.3.176 | 172.16.3.176/31 | 172.16.3.178 |
| Core link B | 172.16.3.178 | 172.16.3.178/31 | 172.16.3.180 |
STEP 4Point-to-point links
Core link A and Core link B each connect exactly two routers, so a /31 is legal for both under RFC 3021: rather than reserving a network address and a broadcast address out of a 4-address /30 and wasting two of them, both addresses in a /31 are usable host addresses. That is why they land in the allocation table below as 172.16.3.176/31 and 172.16.3.178/31 — two addresses each, immediately after Servers, with nothing rounded up or reserved.
Final allocation
| Segment | CIDR | Subnet mask | First host | Last host | Broadcast | Usable | Requested | Spare |
|---|---|---|---|---|---|---|---|---|
| Lecture hall wifi | 172.16.0.0/23 | 255.255.254.0 | 172.16.0.1 | 172.16.1.254 | 172.16.1.255 | 510 | 450 | 60 |
| Student labs | 172.16.2.0/24 | 255.255.255.0 | 172.16.2.1 | 172.16.2.254 | 172.16.2.255 | 254 | 210 | 44 |
| Staff offices | 172.16.3.0/25 | 255.255.255.128 | 172.16.3.1 | 172.16.3.126 | 172.16.3.127 | 126 | 90 | 36 |
| Library kiosks | 172.16.3.128/27 | 255.255.255.224 | 172.16.3.129 | 172.16.3.158 | 172.16.3.159 | 30 | 25 | 5 |
| Servers | 172.16.3.160/28 | 255.255.255.240 | 172.16.3.161 | 172.16.3.174 | 172.16.3.175 | 14 | 12 | 2 |
| Core link A | 172.16.3.176/31 | 255.255.255.254 | 172.16.3.176 | 172.16.3.177 | — | 2 | 2 | 0 |
| Core link B | 172.16.3.178/31 | 255.255.255.254 | 172.16.3.178 | 172.16.3.179 | — | 2 | 2 | 0 |
Add it all up and the same five numbers the planner's Address space section reports for any plan come out here too: a 1,024-address block, 948 addresses allocated across the seven subnets above, 76 left unused — the tail from 172.16.3.180 through 172.16.3.255, since every block in this plan happened to land on a boundary with no gaps in between — 147 spare addresses sitting inside those subnets unused by any host, for a 92.6% utilisation.
Edge rules
Every rule below is something this calculator actually enforces on every plan it computes, not only the campus example above — most subnetting references cover the basic math and leave these out, which is usually where a hand-worked answer and this calculator's answer part ways. Each one comes with the exact number the calculator would produce, so you can check it against your own working.
- 01
The base address is snapped down to its own network boundary, so 192.168.1.77/24 is read as 192.168.1.0/24.
- 02
Usable host counts follow the classic rule: block size minus network and broadcast. A /30 gives 2, a /31 gives 2 (RFC 3021) and a /32 gives 1.
- 03
A segment with exactly one host gets a /32. A segment with exactly two hosts gets a /31.
- 04
Segments with the same host count keep the order you typed them in — the sort is stable.
- 05
Segments that don't fit are listed on their own while every other segment is still placed — see the Will not fit panel for what to try next.
None of these five rules are optional settings — there is nothing to configure and no mode where the calculator behaves differently. Every plan on this site, from the homepage's default example to a hand-typed /8 with sixty segments, follows exactly the same five rules above and the same four steps in Method. That consistency is what makes a result on this site something you can check by hand instead of something you have to take on faith.
FAQ
Straight answers to the questions this calculator gets asked most, one at a time.
What is VLSM and how is it different from regular subnetting?
Regular, fixed-length subnetting splits one network into equal-sized pieces: every subnet gets the same prefix, whether it needs 2 hosts or 200. Variable Length Subnet Masking removes that restriction. Each segment gets a prefix sized to its own host count, so a 450-host wifi segment and a 2-host router link can come out of the same base network without wasting addresses on the small one or starving the large one. It is still ordinary binary subnetting underneath — VLSM just applies a different prefix at every cut instead of one prefix for the whole block.
Why are segments sorted largest first?
Placing the biggest segment first and working down to the smallest is what keeps the base network free of unusable holes. If a small segment were placed before a large one, the large one might not fit in the space left over even though the total free address count is large enough on paper — the gap is simply the wrong shape. Sorting largest first and packing tightly against the previous block, as Align and advance describes, means any space left over sits at the very end of the block in one contiguous piece, where it can still be used for a future segment or reported honestly as unused, instead of being scattered across gaps too small for anything. Segments with the same host count keep the order they were originally typed in, so re-ordering never happens for a reason a user can't see — see Edge rules below for that one.
Why does each segment need hosts + 2 addresses?
Every subnet reserves two addresses that no host can use: the network address, which identifies the subnet itself, and the broadcast address, which every host on it listens to. So a segment asking for 60 hosts is really asking for a block that holds at least 62 addresses — 60 usable plus those two — and the calculator rounds that up to the next power of two, because a valid subnet mask can only cut the address space at power-of-two boundaries. 62 rounds up to 64, a /26. That is also why the usable host count on every subnet card is always two less than the block size, except for the /31 and /32 cases the next question covers, where the network/broadcast reservation doesn't apply at all.
When is a /31 subnet allowed?
A /31 is a two-address block, normally too small to hold a network address, a broadcast address and even one usable host at the same time. RFC 3021 carves out an exception for point-to-point links — the cable between two routers, for example — where there are only ever exactly two devices on the segment and no broadcast is ever needed. Under that RFC, both addresses in a /31 are treated as host addresses, one for each end of the link. This calculator applies that exception automatically whenever a segment asks for exactly 2 hosts, which is why the two-host segments in the worked example above get a /31 instead of the /30 a fixed-length approach would hand out, saving two addresses per link compared to the older convention.
Why did the calculator change my base address?
A network address has to sit on a boundary that its own prefix defines — a /24 network, for instance, can only legally start on a multiple of 256. If you type an address that isn't on that boundary, such as 192.168.1.77/24, the calculator doesn't reject it: it snaps it down to the network address that boundary implies, 192.168.1.0/24, and plans from there. This mirrors what a router does with the same input — the host bits of whatever address you give it are simply ignored once the prefix says how many bits belong to the network. The single-network inspector on this site applies the same rounding rule, so searching any address inside a /24 always resolves to the same network line.
What does "Will not fit" mean and how do I fix it?
Segments are placed largest first against the base network until one of them, once rounded up and aligned to its own boundary, would run past the end of the block. That segment is set aside on a Will not fit list instead of failing the whole plan, and the calculator moves on to try the remaining, smaller segments in the space left — a single oversized segment almost never means every segment is unplaceable. The list shows exactly how many addresses the failing segment needed and what prefix that would have required, so the fix is usually one of two things: widen the base network's prefix — a /23 or /22 instead of a /24, for example — so there is more room overall, or trim the host count on the segment that didn't fit, or on an earlier, larger one that is using more space than it needs.
Is anything I type uploaded anywhere?
No. Every calculation on this site — the VLSM plan, the single-subnet inspection, the notation conversion, and everything on this guide — runs in your browser using plain arithmetic; nothing you type is sent anywhere, because there is no server involved in the computation at all. The only thing this site stores is a local copy of your own inputs, kept in your browser's local storage so they're still there the next time you visit, and that copy never leaves your device either. Clearing your browser's site data for this domain clears it. If this site later shows ads, any cookies those ads set will be disclosed in the Cookie Policy linked from the footer — see Your data never leaves this browser below for the full statement.
Can I export the plan to Excel or a Cisco router?
Yes. Once a plan is valid, the Allocation schedule section on the VLSM plan page offers four export options: Copy table puts a tab-separated copy of the full allocation table on your clipboard, ready to paste straight into Excel or Google Sheets; CSV and Markdown download the same table as a .csv or .md file; and Copy Cisco config copies a ready-to-paste block of interface configuration — one interface stanza per allocated subnet, each with its description, IP address, subnet mask and a no shutdown line — using the first usable address in each subnet as that interface's address. All four read directly from the plan currently on screen, so re-running any export after changing a host count always reflects the latest numbers.
Why does 10101010 read as binary instead of decimal?
This site's IP Address Converter checks formats in a fixed order: dotted decimal first, then 0x-prefixed hex, then a bare digit string, then a plain decimal integer, then 0b-prefixed binary. A bare digit string is read as binary when, after stripping any dots or spaces, it is exactly 8, 16, 24 or 32 characters long and contains only 0s and 1s. 10101010 is 8 digits of only 0s and 1s, so it matches that rule and wins over the plain-decimal check that comes later, even though 10101010 is also a valid decimal number on its own. To force the decimal reading instead, type it in a form that doesn't match the binary rule — a leading zero (010101010) changes the length to 9 digits without changing the value, so it falls through to the decimal-integer rule. Either way, the Integer row in the output always shows the resolved 32-bit value in decimal, so you can read the number your input actually resolved to without needing to guess which rule fired first.
Your data never leaves this browser
Every page on this site carries a short line in the footer promising your inputs stay on this device. That isn't just a tagline — here is the complete, specific statement behind it:
- Every calculation runs in the page. No requests leave the browser, so the sheet keeps working with the network unplugged once it has loaded.
- Your base network and segment list are kept in this browser's local storage and restored on your next visit. Clearing site data clears them.
- This site currently shows no ads. If ads are added later, any cookies they set will be listed in the Cookie Policy, linked from the footer.