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

How to Convert CIDR Notation to a Subnet Mask

Converting CIDR to a subnet mask takes one binary step. Count the bits, fill in ones, convert to decimal.

CIDR notation and dotted-decimal subnet masks express the same information in different formats. Older hardware, Cisco IOS, and some DHCP servers require dotted-decimal masks. Modern cloud consoles and firewall GUIs accept CIDR notation directly. Knowing how to move between formats lets you configure any device regardless of which format it expects.

Binary conversion method

Converting a CIDR prefix to a subnet mask requires filling a 32-bit binary string with n ones followed by (32 minus n) zeros, then grouping into four 8-bit octets and converting each to decimal. For /25: write 25 ones then 7 zeros, giving 11111111.11111111.11111111.10000000. Grouping gives four octets: 255, 255, 255, 128. Consequently, /25 = 255.255.255.128. For /22: write 22 ones then 10 zeros, giving 11111111.11111111.11111100.00000000. The third octet 11111100 = 252. Result: 255.255.252.0.¹ Building on this, the pattern repeats for any prefix. Only the boundary octet (where the ones end) requires binary conversion; preceding octets are always 255 and following octets are always 0.

Common CIDR to mask equivalents

For the most common prefixes, the fourth octet conversions are: /25 → 128 (10000000), /26 → 192 (11000000), /27 → 224 (11100000), /28 → 240 (11110000), /29 → 248 (11111000), /30 → 252 (11111100). Prefixes landing in the third octet: /17 → 255.255.128.0, /18 → 255.255.192.0, /19 → 255.255.224.0, /20 → 255.255.240.0, /21 → 255.255.248.0, /22 → 255.255.252.0, /23 → 255.255.254.0. Building on this, prefixes at exact octet boundaries are trivial: /8 = 255.0.0.0, /16 = 255.255.0.0, /24 = 255.255.255.0. Memorizing the fourth-octet values (128, 192, 224, 240, 248, 252) handles all /25 through /30 conversions without binary arithmetic.¹

Practical application in firewall and router configuration

Cisco IOS requires dotted-decimal subnet masks for interface address commands but uses wildcard masks for ACL rules.² When moving from CIDR documentation to IOS config, convert the prefix to a mask for interface configuration, then invert it for ACL entries. For example, /25 maps to mask 255.255.255.128 for the interface, and you invert that to 0.0.0.127 for the ACL permit statement. Building on this, iptables on Linux accepts both CIDR notation (192.168.1.0/25) and dotted-decimal mask (192.168.1.0/255.255.255.128) for -s and -d arguments. CIDR is simpler to write in iptables, so use the mask form only when interfacing with legacy tools that require it.

Subnet masks in Windows and Linux network configuration

Windows network adapters still accept subnet masks in dotted-decimal format through the GUI at Network Connections > Properties > IPv4, even though PowerShell's New-NetIPAddress accepts CIDR with the -PrefixLength parameter.³ Linux ip addr add 192.168.1.10/24 dev eth0 uses CIDR exclusively, but the legacy ifconfig command requires dotted-decimal masks: ifconfig eth0 netmask 255.255.255.0. Recognizing that 255.255.255.128 is /25 tells you immediately that the subnet holds 126 usable hosts, which is faster than converting mentally each time you encounter an unfamiliar mask in documentation.

Windows GUI versus PowerShell

The Windows GUI masks field at IPv4 adapter properties accepts only dotted-decimal, while PowerShell's New-NetIPAddress and Set-NetIPAddress accept the -PrefixLength parameter directly. When you script adapter configuration in PowerShell, you can pass -PrefixLength 24 instead of -SubnetMask 255.255.255.0, but the GUI still requires the dotted-decimal form. This split means most network engineers keep a small reference table of common masks open when working across both interfaces on the same machine.

Practically, this means a single misconfiguration can slip through when someone copies a -PrefixLength value into the GUI mask box expecting it to mean the same thing. It does not: the GUI field wants 255.255.255.0, not the number 24, so entering 24 there produces an invalid mask that Windows rejects at apply time. Keeping both a CIDR prefix and its dotted-decimal equivalent visible, whether in the calculator or a sticky note, removes the translation step that causes these errors during routine adapter changes.

Linux ip versus ifconfig

The modern ip command uses CIDR exclusively (ip addr add 192.168.1.10/24 dev eth0), while the legacy ifconfig command requires dotted-decimal masks. Most Linux distributions ship ip as the default and deprecate ifconfig, but older scripts and documentation still reference the ifconfig form. When you encounter ifconfig netmask 255.255.255.0 in a script, converting it to /24 lets you migrate the command to the ip tooling that current distributions support.

How DHCP delivers subnet masks to clients

DHCP option 1 delivers the subnet mask alongside the assigned IP address.⁴ RFC 2132 defines the option as a 32-bit value in network byte order, identical to the dotted-decimal representation: 255.255.255.0 for a /24. A DHCP server configured with scope 192.168.10.0/24 automatically sends 255.255.255.0 as option 1 to every client that leases an address in that scope.

How an incorrect DHCP mask breaks routing

An incorrect DHCP mask (sending /16 when the subnet is /24) causes clients to treat the entire 192.168.x.x range as local, bypassing the gateway for addresses beyond the actual subnet. Verifying the mask in DHCP server configuration prevents this class of routing failure, and the CapyToolkit subnet calculator shows the mask alongside the CIDR prefix so you can set both values correctly when configuring DHCP scopes.

Mask-to-prefix conversions in security contexts

Security appliances and firewall platforms sometimes display rules using subnet masks, not CIDR prefixes. FortiOS address objects carry the mask in dotted-decimal form, and its REST API returns the subnet as a string such as 192.0.2.0 255.255.255.0.⁵ Palo Alto Networks uses CIDR slash notation for IP Netmask address objects (for example, 192.168.80.0/24) and reserves dotted-decimal format for wildcard masks, which have inverted bit semantics.⁶ When exporting firewall rules from one platform to another, converting between mask and prefix notation preserves the intended scope. Building on this, the subnet calculator shows what subnet mask a /22 uses as 255.255.252.0, and a rule permitting 10.0.0.0/255.255.255.0 is functionally identical to 10.0.0.0/24, but some platforms parse the mask differently in handling edge cases around /31 and /32, so always verify after conversion.

Masks beyond /24 and their operational patterns

Prefixes shorter than /24 (masks like 255.255.252.0) are routine in datacenter networks where VLANs span hundreds of hosts. Prefixes longer than /24 (masks above 255.255.255.0) dominate in microsegmentation: /28 (255.255.255.240) for database clusters, /30 (255.255.255.252) for point-to-point links between switches. Network engineers who work primarily with cloud consoles may rarely see dotted-decimal masks in daily work, but exam scenarios (CCNA, CompTIA Network+) and legacy device configurations keep the conversion skill essential.

When to use this

Convert CIDR to a subnet mask when configuring a device that requires dotted-decimal format, such as older Cisco IOS versions, some DHCP server software, and legacy firewall appliances.

Examples

interface GigabitEthernet0/0
 ip address 192.168.1.128 /25

interface GigabitEthernet0/0
 ip address 192.168.1.128 255.255.255.128

iptables -A INPUT -s 10.0.0.0/22 -j ACCEPT

iptables -A INPUT -s 10.0.0.0/255.255.252.0 -j ACCEPT

Look Up Your Subnet Mask and CIDR Prefix

Scan the table below instead of running the subnet math yourself: prefix lengths map directly to host counts and block sizes, from /8 through /32, with every subnet mask equivalent listed alongside each one.

Network engineers, system administrators, and cloud architects check these values dozens of times a week. Memorizing /24 = 254 hosts and /30 = 2 hosts covers most cases, but less common prefixes like /22 (1022 hosts) or /19 (8190 hosts) need a lookup. This page gives you the complete IPv4 prefix-to-host-count table with block sizes, subnet masks, wildcard masks, and common use cases for each prefix, and the calculator above confirms any value you are unsure about.

IPv4 CIDR reference table

From /8 to /30, the key values are: /8 = mask 255.0.0.0, block 16M, usable 16,777,214; /16 = 255.255.0.0, block 65,536, usable 65,534; /20 = 255.255.240.0, block 4,096, usable 4,094; /21 = 255.255.248.0, block 2,048, usable 2,046; /22 = 255.255.252.0, block 1,024, usable 1,022; /23 = 255.255.254.0, block 512, usable 510; /24 = 255.255.255.0, block 256, usable 254; /25 = 255.255.255.128, block 128, usable 126; /26 = 255.255.255.192, block 64, usable 62; /27 = 255.255.255.224, block 32, usable 30; /28 = 255.255.255.240, block 16, usable 14; /29 = 255.255.255.248, block 8, usable 6; /30 = 255.255.255.252, block 4, usable 2.¹ This table covers every prefix used in typical LAN, cloud VPC, and WAN link design, so you can scan a single column to find the right prefix for any target host count without performing binary arithmetic each time.

Memorization patterns

The binary doubling rule makes subnet memorization mechanical. Each bit added to the prefix halves the host count. Starting from /24 (254 hosts): /25 is 126, /26 is 62, /27 is 30, /28 is 14, /29 is 6, /30 is 2. Going the other direction: /23 is 510, /22 is 1022, /21 is 2046, /20 is 4094. Building on this, each value is 2^n − 2 where n = 32 − prefix.¹ For block sizes (total addresses, no subtraction): /24 = 256, /25 = 128, /26 = 64, /27 = 32, /28 = 16, /29 = 8, /30 = 4. Furthermore, subnet boundaries always fall on multiples of the block size, so a /26 (block 64) starts at 0, 64, 128, or 192 in the last octet.

Wildcard masks and ACL use

Wildcard masks are the bitwise inverse of subnet masks. Where a subnet mask has 1s in the network bits, a wildcard mask has 0s, and vice versa.² 255.255.255.0 (/24) inverts to 0.0.0.255. Cisco IOS uses wildcard masks in access control lists (ACLs) and OSPF area definitions: access-list 10 permit 192.168.1.0 0.0.0.255 permits the entire /24. Building on this, wildcard masks allow non-contiguous bit matching. For example, 0.0.0.254 matches every even address, though this technique is rarely used outside of route summarization. When writing Cisco ACL entries, always invert the subnet mask to get the wildcard: /26 mask 255.255.255.192 inverts to wildcard 0.0.0.63. With the subnet calculator you can invert a subnet mask for a Cisco ACL, which prevents the common mistake of copying a mask directly into an ACL and wondering why the rule matches the wrong traffic.

Subnetting in classful vs classless routing protocols

Classful routing protocols (RIPv1, IGRP) do not include subnet masks in their route advertisements.³ When a router running RIPv1 advertises 10.0.0.0, receiving routers assume the default classful mask (/8 for Class A, /16 for Class B, /24 for Class C). This means RIPv1 cannot support VLSM or discontiguous networks: every subnet of 10.0.0.0 must use the same mask, and subnets of different major networks cannot share a common supernet. The shift from classful to classless routing in the late 1990s was driven by the need to conserve IPv4 address space, and understanding why classful protocols fail at VLSM helps network engineers evaluate whether legacy equipment still has a place in modern networks.

Why classful protocols break VLSM

Because the mask is not advertised, every router along the path must infer it from the address class. A 10.x.x.x address is always Class A, so RIPv1 assumes /8 even if the network was subnetted to /26. This assumption makes discontiguous subnets (where two subnets of the same classful network are separated by a different classful network) unreachable, because the receiving router applies the wrong mask and drops the route into the wrong aggregate. The result is that every subnet under a classful protocol must use the same mask, eliminating the address conservation that VLSM provides.

How classless protocols solve the problem

Classless routing protocols (RIPv2, OSPF, EIGRP, BGP) include the prefix length in every route update, enabling VLSM and CIDR. Building on this, modern networks exclusively use classless protocols. If you encounter RIPv1 in a legacy environment, the subnet mask must be identical across all subnets of the same major network, which eliminates the address conservation benefits of VLSM.

The subnet calculator helps you identify which prefix lengths are valid under classful constraints: for a Class B address like 172.16.0.0, all subnets must use the same mask, and that mask must be /16 or longer. Migrating to OSPF or EIGRP removes this constraint and allows the variable-length allocations that efficient address planning requires.

Quick-reference subnet planning for common scenarios

Three recurring subnetting scenarios cover most real-world needs, and keeping them in mind lets you skip the calculator during whiteboard sessions and early design conversations. First, point-to-point WAN links use /30 (2 usable addresses) in IPv4 or /127 (RFC 6164) in IPv6.⁴ Second, server segments use /28 (14 usable) for small clusters and /24 (254 usable) for large ones. Third, user access subnets use /22 (1022 usable) for large offices and /24 (254 usable) for smaller floors. Memorizing these three patterns plus the doubling rule handles 90% of planning tasks.

Cloud provider reservation differences

For cloud environments, subtract the provider's reservation count from each prefix: AWS and Azure reserve 5,⁵ GCP reserves 4.⁶ Building on this, a /27 in AWS provides 27 usable addresses (32 minus 5), not the standard 30. The subnet calculator accounts for cloud reservations when you select the cloud mode, giving you the correct usable count for your target provider.

When to use the cheat sheet versus the calculator

Keeping a printed or bookmarked copy of the cheat sheet alongside the calculator covers both quick lookups and precise planning without switching between tools. Use the cheat sheet during whiteboard design sessions or phone conversations where you need a quick reference. Switch to the calculator when you need exact values for a non-standard prefix, cloud reservation math, or binary breakdowns of an arbitrary mask.

When to use this

Check this table when writing firewall rules, configuring router ACLs, or planning subnets away from a keyboard. When you need to verify an exact value instead of trusting memory, run the same prefix through the calculator above.

Examples

ip access-list extended PERMIT-WEB
 permit ip 192.168.1.64 255.255.255.192 any

ip access-list extended PERMIT-WEB
 permit ip 192.168.1.64 0.0.0.63 any