How to Convert a Subnet Mask to CIDR Notation

How to Convert a Subnet Mask to CIDR Notation

A dotted-decimal subnet mask carries the same routing information as a CIDR prefix, expressed in a older format that many cloud consoles and firewalls no longer accept directly. Counting the consecutive 1-bits in the mask gives you the prefix length those tools expect.¹

When reading router configs, DHCP leases, or legacy network documentation, you often find subnet masks in dotted-decimal format (255.255.255.0) instead of CIDR (/24). Translating between the two lets you enter an address into any modern tool without confusion.

The bit-counting method

A subnet mask is a 32-bit value where the network portion is marked with 1-bits and the host portion with 0-bits, so finding the CIDR prefix means counting how many 1-bits appear starting from the leftmost bit position and stopping at the first zero. Most masks fall on an octet boundary (/8, /16, /24), but many real-world networks use a boundary inside an octet, which is the case that trips people up.

Counting the 1-bits in a dotted-decimal mask

255.255.255.0 in binary is 11111111.11111111.11111111.00000000; counting 24 consecutive ones before the first zero gives /24.¹ For 255.255.252.0, the third octet 252 in binary is 11111100, so adding the 8 full ones from the first two octets (16) plus 6 ones from the third octet gives /22. The only octet that requires binary conversion is the one that contains the ones-to-zeros boundary, because all preceding octets are 255 (8 ones each) and all following octets are 0.

Once you have counted the ones in that boundary octet, adding the contributions from the full 255 octets gives the final prefix length directly, which is exactly what the calculator displays when you enter a dotted-decimal mask into the input field. This avoids the common mistake of converting every octet to binary when only the boundary octet actually needs that step.

Shortcut formula for full-byte octets

Building on this, the shortcut is: total ones = 8 multiplied by the count of 255 octets, plus the number of ones in the boundary octet. Memorizing the eight boundary values (128, 192, 224, 240, 248, 252, 254, 255) and their bit counts (1 through 8) lets you compute the prefix length at a glance without writing out the full binary string for every octet.

Common mask to CIDR equivalents

The fourth-octet boundary values and their CIDR contributions: 128 (10000000) = 1 bit → /25; 192 (11000000) = 2 bits → /26; 224 (11100000) = 3 bits → /27; 240 (11110000) = 4 bits → /28; 248 (11111000) = 5 bits → /29; 252 (11111100) = 6 bits → /30; 254 (11111110) = 7 bits → /31.² Adding 8 for each full 255 octet: 255.255.255.192 = 8+8+8+2 = /26.

Third-octet boundary values follow the same pattern, shifted by 16 bits: 128 → /17, 192 → /18, 224 → /19, 240 → /20, 248 → /21, 252 → /22, 254 → /23. Recognizing any of these values on sight eliminates the need for binary conversion in most practical situations, which is why the calculator lists both octet position and prefix together.

Identifying invalid subnet masks

Valid subnet masks must be a contiguous block of ones followed by zeros, with no gaps and no alternating bits.³ A mask like 255.0.255.0 is invalid: 255 in binary is 11111111, then 0 is 00000000, then 255 again, which alternates between ones and zeros instead of forming a contiguous block. If you encounter such a pattern in a legacy configuration, it almost always indicates a misconfiguration rather than a deliberate non-standard subnet.

Legacy non-contiguous masks are not valid today

Some very old routing software accepted non-contiguous masks for policy-based routing, but modern equipment does not support them, and IPv6 explicitly forbids them. Consequently, if a subnet mask does not match one of the standard contiguous forms above, treat it as a config error and report it rather than trying to convert it to CIDR. When the subnet calculator rejects a mask as invalid, the most likely cause is a gap in its binary 1-bit sequence.

Parsing subnet masks from router configurations

Legacy Cisco IOS configurations display subnet masks in dotted-decimal throughout: interface GigabitEthernet0/0 receives ip address 10.0.0.1 255.255.255.0 and access-list 10 permits 192.168.1.0 0.0.0.255 (where 0.0.0.255 is a wildcard mask, not a subnet mask).⁴ Converting these to CIDR for modern documentation requires recognizing that 255.255.255.0 is /24 and that 255.255.255.240 is /28.

When migrating from an older firewall that stores rules with dotted-decimal masks to a modern cloud security group that expects CIDR prefixes, a simple mapping table handles the conversion for the 9 valid fourth-octet values. CapyToolkit performs this conversion bidirectionally: enter either format and see the equivalent in the other. For Cisco wildcards specifically, invert the wildcard to get the subnet mask, then count the bits: 0.0.0.255 inverts to 255.255.255.0, which is /24.

Subnet masks in virtualization and container networking

VMware ESXi vSphere port groups and Proxmox VE virtual networks accept subnet masks in dotted-decimal format.⁵ Docker's default bridge network uses 172.17.0.0/16, but custom bridge networks defined with a CIDR block (for example 192.168.100.0/24 created via the Docker CLI) use CIDR notation explicitly.⁶ Kubernetes CNI plugins such as Calico, Flannel, and Cilium configure pod CIDR ranges in CIDR notation through the Kubernetes API, but the underlying node network interfaces are typically configured with netplan on Linux, which accepts either format.⁷

Recognizing that netplan's addresses: [10.0.0.1/24] is equivalent to addresses: [10.0.0.1] with gateway: 10.0.0.254 and netmask: 255.255.255.0 prevents configuration errors when translating between formats across documentation and tools. The calculator output provides both the CIDR prefix and dotted-decimal mask, so you can enter the correct format for whichever tool you are configuring.

Common mask-to-CIDR mistakes and how to avoid them

The most frequent error in mask-to-CIDR conversion is misidentifying the boundary octet: a mask of 255.255.252.0 looks similar to 255.255.240.0, but the former is /22 and the latter is /20, a difference of 3072 usable addresses. Another common mistake is assuming the mask always starts at an octet boundary, when in fact a third-octet mask means the prefix falls between /17 and /24 and only the specific boundary value determines the exact prefix.

Masks with non-contiguous 1-bits have no CIDR equivalent

Non-contiguous subnet masks, where the 1-bits are not all consecutive, do not have a valid CIDR equivalent because CIDR requires a single prefix length. Legacy IPX/SPX networks and very old policy-based routing configurations occasionally used non-contiguous masks, but these are invalid in IPv4 and IPv6. The subnet calculator converts a firewall's dotted-decimal mask to CIDR, and it flags gaps in the binary 1-bit sequence when that mask is non-contiguous.

When to use this

Convert a subnet mask to CIDR when you find dotted-decimal masks in legacy configurations and need to enter the equivalent prefix into a modern tool, cloud console, or firewall rule.

Examples