A complete guide to the IPv4 and IPv6 subnet calculators, the VLSM splitter, and why IPv6 math requires BigInt arithmetic for correct results.
Launch the IP Subnet Calculator →The IP Subnet Calculator is the most comprehensive networking tool on NexTechTools, combining four distinct functions in one page: a full IPv4 subnet calculator, a full IPv6 subnet calculator, a VLSM (Variable Length Subnet Masking) splitter for dividing a parent network into multiple smaller subnets, and quick-reference tables covering IPv4 address classes and the standard private, non-routable address ranges defined by RFC 1918 and related standards.
Switching between IPv4 and IPv6 mode is handled by a toggle at the top of the page, since the two protocols require genuinely different underlying math (32-bit integer arithmetic for IPv4 versus 128-bit arithmetic for IPv6, which exceeds what JavaScript's native number type can handle precisely, requiring a different approach entirely, covered in detail below).
Entering an IPv4 address and a CIDR prefix length produces a comprehensive breakdown: the CIDR notation itself, the address's traditional network Class (A, B, C, D, or E, a historical classification system described further below), the subnet mask in both dotted-decimal and binary form, the wildcard mask (the inverse of the subnet mask, used in some router and firewall access-list configurations), the IP address in hexadecimal, the network address, the broadcast address, the total number of addresses in the range, the number of usable host addresses, and the specific usable host address range.
The distinction between "total addresses" and "usable hosts" matters and is deliberately shown as two separate figures: in any standard subnet of size /30 or smaller (meaning not a /31 or /32 point-to-point case), the very first address in the range is reserved as the network address and the very last is reserved as the broadcast address, neither of which can be assigned to an actual device. A /24 network, for example, contains 256 total addresses but only 254 usable host addresses once the network and broadcast addresses are excluded.
Two edge cases get special handling: a /31 network (historically unusual, but standardized specifically for point-to-point links in RFC 3021) has only 2 addresses total, both of which are usable, since there's no room for separate network and broadcast addresses in such a small block. A /32 represents a single, individual host address with no concept of a separate network or broadcast address at all.
The reference table showing Classes A through E reflects the original, pre-1993 way IPv4 address space was divided, before CIDR notation was introduced specifically to replace this rigid classification system with flexible, arbitrary-length prefixes. Under the old classful system, a Class A address block always used an 8-bit network portion, every Class B block always used 16 bits, and every Class C block always used 24 bits, regardless of how many hosts a given network actually needed, which was recognized as deeply wasteful of the limited IPv4 address space as internet adoption grew.
Despite being technically obsolete as an addressing scheme, the classful system is retained here as a reference specifically because the terminology still appears constantly in networking documentation, training materials, and casual conversation among IT professionals, even decades after CIDR made it technically unnecessary. Knowing that an address starting with 192 falls in the traditional "Class C" range, for instance, remains a quick, commonly understood way to communicate roughly how large a historically-styled network might be, even in a modern, fully CIDR-based environment.
IPv4 addresses are 32 bits long, which fits comfortably within JavaScript's native number type without any precision concerns for the kind of bitwise operations (shifting, masking, combining) that subnet calculations require. IPv6 addresses are 128 bits long — four times larger — which is well beyond what JavaScript's standard number type can represent and manipulate precisely using normal arithmetic and bitwise operators.
To correctly perform IPv6 subnet math, this tool uses JavaScript's BigInt type, a built-in feature for working with arbitrarily large integers with full precision, rather than the standard floating-point-based number type used for ordinary arithmetic. Every step of the IPv6 calculation — parsing the address into its eight 16-bit hex groups, converting those groups into a single large integer, applying the subnet mask, calculating the network and broadcast-equivalent last address, and converting the results back into properly formatted and compressed IPv6 notation — is written using BigInt-specific operators and functions rather than the ordinary arithmetic used throughout the IPv4 calculator.
This distinction matters because a naive attempt to handle 128-bit IPv6 math using JavaScript's regular number type would silently produce incorrect results for large values due to floating-point precision limits, without necessarily throwing any error to indicate something had gone wrong — exactly the kind of silent miscalculation that matters enough to require deliberate, correct handling rather than an easy shortcut.
IPv6 addresses are long and visually unwieldy in their fully expanded form (eight groups of four hexadecimal digits each, separated by colons), so the IPv6 standard defines a compression rule allowing the longest single run of consecutive all-zero groups to be collapsed into a double-colon (::) shorthand, and this tool implements that compression correctly when displaying its calculated results, rather than only showing the unwieldy expanded form.
The compression logic specifically finds the longest run of zero groups, since the standard only permits one double-colon per address, and if a shorter run were collapsed while a longer one was left expanded, the address would still be valid but needlessly longer than the properly compressed form. The tool was built to find and compress the longest qualifying run every time, matching how any properly implemented IPv6 tool is expected to behave.
The fully expanded address 2001:0db8:0000:0000:0000:0000:0000:0001 compresses correctly to 2001:db8::1, collapsing the six consecutive zero groups into a single double-colon, which is both shorter to read and the technically correct canonical compressed form of that address.
The Variable Length Subnet Masking splitter divides a parent network into multiple equally-sized smaller subnets, letting you choose between two input modes: specifying how many separate subnets you need, or specifying how many usable hosts each resulting subnet must support. Both modes ultimately calculate the same underlying thing — the correct new CIDR prefix length — just working backward from a different starting requirement.
When splitting by number of networks needed, the tool calculates the minimum number of additional bits required so that two raised to that many bits is at least as large as the requested network count. When splitting by hosts needed per subnet, it instead calculates the minimum number of host bits required so that two raised to that power, minus two (again accounting for the reserved network and broadcast addresses), covers the requested host count.
Every resulting subnet is displayed in a scrollable table showing its network address and CIDR, usable host range, broadcast address, and usable host count, with a hover tooltip on each network/CIDR value revealing the exact subnet mask — useful for anyone who thinks more naturally in dotted-decimal mask notation than in CIDR prefix lengths. As a safeguard against generating an unreasonably large, unusable table, the tool caps output at 4,096 subnets, returning a clear error message rather than attempting to render thousands of rows if an unrealistic combination of parent network size and subnet size is requested.
The reference table listing RFC 1918 private address ranges (10.0.0.0/8, 172.16.0.0/12, and 192.168.0.0/16) along with related special-purpose ranges like 100.64.0.0/10 (Carrier-Grade NAT, used by ISPs for shared address space per RFC 6598), 169.254.0.0/16 (link-local APIPA addresses that Windows and other operating systems self-assign when no DHCP server is available, per RFC 3927), and 127.0.0.0/8 (the loopback range used for a device to refer to itself) is included because recognizing these ranges on sight is a fundamental, constantly-used skill in network administration.
These ranges are specifically carved out and guaranteed by official internet standards to never be routed on the public internet, which is exactly why they're safe to reuse identically across millions of separate private networks worldwide (your home router's internal network almost certainly uses one of these ranges, as does every other home router on the planet, without any actual conflict, since none of that traffic is ever meant to traverse the public internet directly).
Every calculation in this tool, across IPv4, IPv6, and VLSM splitting, happens entirely within your browser using standard (and BigInt, for IPv6) arithmetic. No network request of any kind is made by this tool, and no address or network information you enter is ever transmitted anywhere, logged, or stored.
RFC 3021 specifically standardized /31 networks for point-to-point links, recognizing that reserving a network and broadcast address in a block of only 2 addresses would waste the entire block for links that only ever connect exactly two devices directly.
The tool caps output at 4,096 subnets as a practical safeguard against generating an unusably large table. If your parent network and requested subnet size would produce more than that, try a larger subnet size (fewer total subnets) or a smaller parent network.
Technically, no — CIDR notation replaced the classful system decades ago, and real-world networks are no longer restricted to Class A/B/C boundaries. It's retained here purely as a widely-recognized reference, since the terminology remains common in networking conversation and documentation.
IPv6 addresses are 128 bits long, which exceeds the precision JavaScript's standard number type can reliably handle for bitwise operations. BigInt provides full, correct precision for arbitrarily large integers, which is necessary to get accurate IPv6 subnet calculations rather than silently incorrect ones.