A complete mathematical guide to binary/decimal/hex IP conversion, CIDR notation, and subnetting — with worked examples and cloud networking context.
Computers fundamentally operate using binary — sequences of 0s and 1s representing the on/off states of electronic switches at the hardware level. Every piece of data a computer processes, including IP addresses, ultimately exists as binary at the machine level, regardless of how we choose to DISPLAY that data for human convenience. The dotted-decimal notation we use for IPv4 addresses (like 192.168.1.1) is purely a human-readability convention layered on top of the actual underlying 32-bit binary value that networking hardware and software actually process.
Understanding this binary foundation isn't just academic trivia — it's essential for genuinely understanding how subnetting, CIDR notation, and routing decisions actually work, since all of these concepts are fundamentally about manipulating and comparing binary bit patterns, even though we typically interact with them through decimal or CIDR shorthand notation for convenience.
As TCP/IP networking grew from an academic research project into the foundation of global business infrastructure through the 1980s and 1990s, an entire educational industry emerged around teaching network engineers the binary mathematics underlying IP addressing and subnetting. Professional certifications like Cisco's CCNA famously dedicate substantial curriculum time to subnetting calculations, reflecting the reality that, despite modern tools automating much of this math, a genuine working understanding of the underlying binary logic remains essential for diagnosing network problems, designing efficient address allocations, and communicating clearly with other networking professionals using shared technical vocabulary.
This educational tradition explains why subnetting questions remain a perennial feature of technical interviews and certification exams even decades after the underlying technology was standardized — the ability to mentally manipulate binary address boundaries remains a genuine marker of networking competence that automated tools, however convenient, don't fully substitute for in professional practice.
CIDR (Classless Inter-Domain Routing), introduced in 1993 through RFC 1518 and RFC 1519, represented a fundamental shift in how the internet allocated and routed IP address space. Before CIDR, IP addresses were allocated in rigid "classes" (Class A, B, and C networks) with fixed, inflexible size boundaries — a Class C network always provided exactly 256 addresses, a Class B always provided exactly 65,536, with nothing in between possible. This rigidity led to enormous waste: an organization needing 300 addresses had no choice but to receive an entire Class B allocation (65,536 addresses) since no class existed between C and B, leaving the vast majority of allocated addresses permanently unused.
CIDR eliminated these rigid boundaries entirely, allowing network allocations of ANY size defined simply by specifying how many bits constitute the network portion (the "/24" or "/27" notation). This flexibility, combined with VLSM (Variable Length Subnet Masking) — the practice of further subdividing an allocated network into multiple differently-sized subnets based on each subnet's actual needs — dramatically improved address space efficiency industry-wide, extending the usable lifespan of the limited IPv4 address pool by years compared to continuing under the old rigid class system.
Consider a growing company starting with a single /24 network (256 addresses) for their entire office, eventually needing to separate traffic for security and performance reasons across multiple departments: Engineering (needing roughly 50 addresses), Sales (needing roughly 20), Guest WiFi (needing roughly 30, deliberately isolated from internal systems), and a Server room (needing just 10 static addresses for critical infrastructure). Rather than wastefully allocating equal-sized subnets to each department regardless of actual need, VLSM allows precisely right-sized allocations: a /26 (62 usable hosts) for Engineering, a /27 (30 usable hosts) for Sales, another /27 for Guest WiFi, and a /28 (14 usable hosts) for the Server room — efficiently using the available /24 space while leaving room for future growth in unallocated remaining ranges.
A more complex real-world scenario involves a company with multiple physical office branches connected via point-to-point WAN links to a central headquarters. Each point-to-point link genuinely needs only 2 usable addresses (one for each end of the connection) — making a /30 subnet (providing exactly 2 usable addresses) the textbook-efficient choice for this specific use case, rather than wastefully allocating a larger subnet that would leave dozens of unused addresses on a connection that fundamentally only ever needs two devices to communicate.
A frequent error among those newer to subnetting involves forgetting that the network address (all host bits set to zero) and broadcast address (all host bits set to one) within any subnet are reserved and cannot be assigned to actual devices — meaning a /24 subnet provides 256 total addresses but only 254 USABLE addresses for devices, a distinction this tool's CIDR Calculator makes explicit by showing both figures separately. Another common mistake involves miscounting required bits when planning VLSM allocations — remembering that the number of usable subnets from borrowing N bits is 2 to the power of N, and usable hosts per subnet is 2 to the power of remaining host bits, minus 2 for the reserved network/broadcast addresses, prevents the frustrating experience of designing an allocation scheme that looks correct on paper but doesn't actually accommodate the planned device count once the reserved addresses are properly subtracted.
Despite modern tools (including this one) automating IP address format conversions, understanding WHY these conversions work, not just mechanically performing them, provides genuine practical value. Network packet captures and low-level debugging tools frequently display addresses and data in hexadecimal format, since hex provides a more compact representation of binary data than decimal while remaining easier for humans to parse than raw binary strings. Firewall rule configurations, particularly on enterprise-grade equipment, sometimes require hex-formatted subnet masks or address ranges in certain configuration contexts. Understanding the underlying binary logic connecting all these representations — rather than treating each format as an isolated, unrelated encoding — makes working across these different technical contexts significantly more intuitive than memorizing conversion tables without comprehending the underlying mathematical relationship.
While this guide and tool focus primarily on IPv4 addressing mathematics, it's worth noting that IPv6 introduces its own, considerably more complex addressing and subnetting conventions, using 128-bit addresses (compared to IPv4's 32 bits) typically represented in hexadecimal notation grouped into eight groups of four hex digits. The sheer scale of IPv6's address space fundamentally changes some subnetting conventions — rather than carefully conserving every individual address as IPv4 subnetting traditionally emphasized, IPv6 network design typically allocates generously sized subnets (a /64 is the standard recommended minimum for any individual network segment, providing more addresses than the ENTIRE IPv4 address space many times over) since address scarcity is no longer the binding constraint it was under IPv4.
While this tool automates the conversion instantly, understanding the manual process builds genuine intuition valuable for quick mental estimation during network troubleshooting. To convert a decimal octet (0-255) to binary, repeatedly divide by 2 and track remainders, or use the faster subtraction method: starting with the largest power of 2 less than or equal to your number (128, 64, 32, 16, 8, 4, 2, 1), subtract it if it fits (recording a 1 for that position) or skip it if it doesn't (recording a 0), then continue with the remainder against the next smaller power of 2.
For example, converting 192: does 128 fit into 192? Yes (recording 1), remainder 64. Does 64 fit into 64? Yes (recording 1), remainder 0. Since the remainder is now 0, all remaining positions (32, 16, 8, 4, 2, 1) record 0. Result: 11000000, matching exactly what this tool's Binary converter would show. This subtraction method, once practiced a few times, becomes fast enough for genuine mental math during real troubleshooting scenarios where you don't have access to a calculator or this tool.
The reverse process is even more straightforward: for each bit position that contains a 1, add its corresponding place value (128, 64, 32, 16, 8, 4, 2, or 1 depending on position), ignoring positions containing 0. For binary 11000000: position 1 (value 128) contains 1, contributing 128. Position 2 (value 64) contains 1, contributing 64. All remaining positions contain 0, contributing nothing. Sum: 128 + 64 = 192, confirming our earlier conversion was correct. This bidirectional verification — converting decimal to binary and then back to decimal as a check — is a useful habit when performing subnetting calculations manually, catching simple arithmetic errors before they propagate into incorrect network design decisions.
A subtle but important rule in subnet masking is that the network bits (represented by 1s in the subnet mask) must always be contiguous from the left, with host bits (0s) contiguous from the right — you cannot have a "valid" subnet mask like 255.0.255.0, which would represent non-contiguous 1s and violate the fundamental logic of how network/host division works. This isn't an arbitrary restriction; it reflects the underlying mathematical purpose of a subnet mask: performing a bitwise AND operation between an IP address and its mask to determine the network address, which only produces a sensible, useful result when the mask's 1-bits form a single contiguous block from the most significant bit. Modern networking equipment and software will typically reject or behave unpredictably with non-contiguous masks, which is why all standard subnet mask values (255.255.255.0, 255.255.255.128, 255.255.255.192, etc.) follow this contiguous pattern, corresponding directly to the valid range of CIDR prefix lengths from /0 to /32.
Particularly in Cisco networking equipment configuration (access control lists and certain routing protocol configurations), you'll encounter "wildcard masks" — essentially the mathematical inverse of a standard subnet mask, where every bit is flipped (0s become 1s and vice versa). While a subnet mask of 255.255.255.0 specifies "match the first 24 bits exactly, any value allowed in the remaining 8 bits" when used in its normal context, the equivalent wildcard mask 0.0.0.255 expresses the same underlying boundary but is used in a different configuration context (typically access control list rules) where the convention historically inverted for reasons rooted in how early Cisco IOS access list matching logic was implemented. This tool's CIDR Calculator displays both the standard subnet mask AND its wildcard mask equivalent, since networking professionals regularly need to translate between these two conventions depending on which specific configuration context they're working in.
While IP address mathematics originated specifically for networking purposes, the underlying binary, decimal, and hexadecimal conversion skills have broader applicability that makes this knowledge valuable beyond network engineering specifically. Programming and software development frequently require working with binary bit manipulation for tasks like flags and permissions systems (where individual bits represent different boolean states packed efficiently into a single value), color representation in web design and graphics (hex color codes like #FF5733 use exactly the same hexadecimal conversion principles as IP address hex representation), and low-level systems programming where understanding how data is actually represented in memory remains genuinely important despite higher-level programming languages abstracting much of this complexity away from typical day-to-day development work.
Before CIDR's introduction, the original IPv4 addressing scheme divided the address space into five classes based on the value of the first octet: Class A (1-126, providing massive /8 networks with over 16 million addresses each, allocated to only a handful of organizations during the internet's earliest days), Class B (128-191, /16 networks with 65,536 addresses each), Class C (192-223, /24 networks with 256 addresses each, the most commonly allocated size for typical organizations), Class D (224-239, reserved for multicast traffic rather than standard host addressing), and Class E (240-255, reserved for experimental future use). This tool's CIDR Calculator still displays this legacy class information alongside modern CIDR notation, since understanding an IP's historical class can occasionally provide useful context (our IP Lookup guide covers how this legacy classification still occasionally surfaces in modern geolocation data), even though virtually all modern networking has moved entirely to classless CIDR-based allocation and routing, with the original class system now serving primarily as a historical reference point and occasional source of legacy terminology still used colloquially among experienced networking professionals.
Let's work through a complete example combining everything covered in this guide. Starting with 192.168.10.0/24 and needing exactly 8 equal-sized subnets, first determine how many bits must be borrowed from the host portion: since 2 to the power of 3 equals 8, we need to borrow exactly 3 bits, moving from a /24 prefix to a /27 prefix (24 + 3 = 27). Each resulting /27 subnet provides 32 total addresses (2 to the power of 5 remaining host bits), with 30 usable addresses after reserving the network and broadcast addresses for each subnet.
The eight resulting subnets, in order, are: 192.168.10.0/27 (usable range .1 to .30), 192.168.10.32/27 (usable .33 to .62), 192.168.10.64/27 (usable .65 to .94), 192.168.10.96/27 (usable .97 to .126), 192.168.10.128/27 (usable .129 to .158), 192.168.10.160/27 (usable .161 to .190), 192.168.10.192/27 (usable .193 to .222), and 192.168.10.224/27 (usable .225 to .254). Notice each subnet's network address increases by exactly 32 (the block size) from the previous one — this consistent, predictable pattern is the mathematical signature of equal-size subnetting, and verifying this pattern is a quick sanity check that your manual calculations are correct before deploying any subnetting scheme into actual production network configuration.
While equal-size subnetting (as demonstrated above) is mathematically elegant and easy to calculate, it's not always the most EFFICIENT real-world choice. If your eight conceptual "departments" have wildly different actual size requirements — one needing just 5 devices, another needing 100 — forcing equal /27 subnets on all of them wastes significant address space on the smaller departments while potentially not providing enough room for the larger one. This is precisely the scenario where VLSM (covered earlier in this guide) becomes valuable: calculating each subnet's size independently based on actual need, rather than mechanically applying equal division, typically produces a more efficient overall allocation that better matches real organizational requirements while still leaving reasonable room for each segment's future growth.
Each converter on this page is designed to accept input in EITHER direction without requiring you to specify which format you're providing — entering a standard IPv4 address into the Binary converter automatically shows you its binary equivalent, while entering a binary string automatically converts it back to IPv4, with the same bidirectional behavior across the Decimal and Hex converters. This auto-detection removes a small but real friction point compared to tools that require you to manually select "convert FROM binary" versus "convert TO binary" before processing your input, letting you simply paste whatever value you have and immediately see all the useful related representations.
Because IPv4 addresses are represented as 32-bit UNSIGNED integers (meaning no negative values are possible, with the full range running from 0 to 4,294,967,295), any decimal value outside this range cannot represent a valid IPv4 address, and any binary input longer than 32 bits similarly has no valid IPv4 interpretation. This tool validates input ranges before performing conversions, providing a clear error message rather than silently producing an incorrect or truncated result — a deliberate design choice prioritizing correctness over attempting to guess what you might have meant when given malformed or out-of-range input.
Whether you're studying for a networking certification, debugging a firewall rule, or simply curious about what's actually happening behind the dotted-decimal notation you see every day, the conversions and calculations covered in this guide form a genuinely foundational layer of practical networking knowledge that pays dividends across an entire career, far beyond any single tool or specific task.
If this guide has sparked deeper interest in networking fundamentals, the natural next topics to explore include routing protocols (how routers actually decide where to send packets based on the network/host division covered here), DHCP server configuration (how IP addresses are automatically assigned within a subnet you've designed), and IPv6 transition mechanisms (how networks gradually migrate from IPv4 while maintaining compatibility). Each builds directly on the binary and subnetting foundation established in this guide, making the time invested in genuinely understanding these mathematical building blocks a worthwhile long-term investment for anyone pursuing networking, system administration, or cybersecurity as a career path.
While this guide has grounded its examples in traditional office network scenarios, the identical subnetting mathematics underlies modern cloud infrastructure design at a much larger scale. Cloud providers like AWS, Azure, and Google Cloud all require customers to define Virtual Private Cloud (VPC) address ranges using exactly the same CIDR notation covered throughout this guide, then further subdivide those ranges into subnets for different availability zones, application tiers, or security boundaries — meaning the manual subnetting skills this guide has built directly transfer to configuring modern cloud networking, just applied to virtual rather than physical network infrastructure (once deployed, our IP Lookup tool can confirm exactly which cloud region and ASN a given public-facing instance actually landed in).
Cloud networking introduces some scale-specific considerations worth noting: cloud providers typically reserve additional addresses beyond the standard network/broadcast reservation covered earlier (AWS, for instance, reserves five addresses per subnet rather than the traditional two, reserving additional addresses for internal DNS and future use), meaning cloud subnet planning should account for these provider-specific reservations beyond the baseline mathematics this guide has covered, checking each specific provider's documentation for their exact reservation policy before finalizing subnet size planning for cloud deployments.
Beyond the conceptual mistakes covered earlier in this guide, certain subnetting errors specifically tend to cause genuine production incidents rather than just inefficient address allocation. Overlapping subnet ranges — accidentally allocating two supposedly-separate subnets that actually share address space — can cause genuinely confusing, intermittent routing problems that are notoriously difficult to diagnose, since traffic behavior may appear to work correctly some of the time depending on which specific device happens to respond to a given request. Insufficiently-sized subnets that run out of available addresses as an organization grows are another common real-world failure mode, typically discovered at an inconvenient moment when a new device or service cannot be provisioned because the planned subnet has been fully allocated, requiring an unplanned, potentially disruptive re-numbering effort that careful upfront capacity planning (allocating meaningfully more address space than current needs require) would have avoided entirely — auditing an entire address range's current utilization across many hosts at once is exactly the kind of task our Bulk IP Lookup tool (see the bulk auditing guide) was built for.
Beyond pure address-space efficiency, subnetting decisions carry meaningful security implications, since subnet boundaries commonly align with firewall and access control boundaries in typical network security architecture. Placing genuinely different trust levels (a public-facing web server tier versus an internal database tier, for example) into separate subnets enables firewall rules to enforce appropriate traffic restrictions between them based on subnet membership, a foundational security architecture pattern sometimes called network segmentation. This security dimension means subnetting decisions should consider not just current and projected device counts (the primary mathematical focus of this guide), but also which devices genuinely need to communicate freely with each other versus which boundaries should enforce more restrictive, deliberately-configured traffic rules — turning subnet design into a security architecture decision as much as a pure address-math exercise.
While this guide has focused specifically on IPv4 mathematics given its continued widespread relevance, readers curious about IPv6's considerably different subnetting philosophy may find it genuinely surprising how much simpler IPv6 subnet planning becomes once IPv4's address-conservation mindset is set aside. With IPv6's vastly larger address space, the standard practice allocates a generous /64 to literally every individual network segment regardless of how few devices it will ever contain, eliminating the careful host-count-based sizing calculations this entire IPv4-focused guide has covered. This represents a genuinely different design philosophy — rather than carefully conserving a scarce resource through precise mathematical optimization, IPv6 network design generally optimizes for SIMPLICITY and consistent, predictable subnet sizing, since the address space is large enough that conservation-driven optimization provides little practical benefit while adding meaningful planning complexity.
Despite calculators and tools (including this one) making manual subnetting mathematics increasingly optional for day-to-day practical work, genuine understanding of the underlying binary logic remains a meaningful marker of networking competence and a practically useful skill for troubleshooting, design review, and clear communication with other networking professionals. This guide has aimed to build that genuine understanding rather than simply presenting calculation shortcuts — knowledge that, once internalized, transforms IP addressing from an intimidating, error-prone manual process into a comprehensible, even satisfying, mathematical system with clear, learnable rules governing every calculation this guide has covered.
Bringing this guide's mathematical concepts directly back to the tool above: when the CIDR Calculator shows "Usable Hosts: 254" for a /24, that's the 256 total addresses minus the 2 reserved (network and broadcast) addresses this guide explained in detail. When the Subnet Calculator shows "Subnets Created: 8" after requesting 8 subnets (see the full subnetting guide for the underlying math), that confirms your requested count was already an exact power of 2, requiring no rounding up as the worked example earlier in this guide demonstrated for non-power-of-2 requests. Connecting each tool output back to the underlying mathematical concept it represents, rather than treating the tool as an opaque black box, is precisely the kind of genuine understanding this guide has aimed to build throughout.
With this connection made explicit, every number this tool displays should now read as the meaningful output of a specific, learnable calculation rather than an unexplained result to simply accept at face value.
Whether you arrived at this guide needing a quick conversion or seeking genuine conceptual understanding, the mathematics underlying IP addressing rewards the modest investment of attention this guide has asked of its readers.
Bookmark the tool above for quick future conversions, but carry the underlying mental model from this guide forward as the more durable, transferable takeaway.
Networking mathematics, once demystified, rarely remains intimidating for long.
That, ultimately, is this guide's central goal.
IP Converter Tool is 100% free, no signup required.
🚀 Open IP Converter Tool