/^/
HardNetworking7 min read

IPv4 CIDR Notation Regex

Validates an IPv4 address in CIDR notation, ensuring each of the four octets falls within 0-255 and the prefix length after the slash falls within 0-32.

#ipv4#cidr#networking#subnet#validation#regex

Regex Pattern

^(?:(?:25[0-5]|2[0-4]\d|1\d\d|[1-9]?\d)\.){3}(?:25[0-5]|2[0-4]\d|1\d\d|[1-9]?\d)\/(?:3[0-2]|[12]?\d)$

Pattern Breakdown

Hover over a token to see what it does.

^(?:(?:25[0-5]|2[0-4]\d|1\d\d|[1-9]?\d)\.){3}(?:25[0-5]|2[0-4]\d|1\d\d|[1-9]?\d)\/(?:3[0-2]|[12]?\d)$
TokenMeaning
^Anchors the match to the start of the string
25[0-5]Matches 250 through 255
2[0-4]\dMatches 200 through 249
1\d\dMatches 100 through 199
\/Literal forward slash separating the address from the prefix length
3[0-2]|[12]?\dMatches a CIDR prefix length from 0 to 32
$Anchors the match to the end of the string

Detailed Explanation

What it does

This pattern checks that a string is a valid IPv4 address followed by a CIDR prefix length, such as 192.168.1.0/24. It validates numerically that each of the four dot-separated octets is between 0 and 255, and that the prefix length after the slash is between 0 and 32.

Why it works

Because a plain `\d{1,3}` would also accept invalid octets like 999, the pattern instead uses a four-way alternation (`25[0-5]|2[0-4]\d|1\d\d|[1-9]?\d`) ordered from the most specific range down to the most general, so the engine correctly matches numbers only within 0-255. The same numeric-range technique is reused for the prefix length, alternating `3[0-2]` for 30-32 with `[12]?\d` for 0-29, keeping the whole prefix within the valid 0-32 range for IPv4 subnetting.

Common use cases

  • Validating subnet input fields in firewall rule or VPC configuration UIs
  • Parsing and checking CIDR ranges from infrastructure-as-code files before applying them
  • Filtering log entries or access-control lists for well-formed CIDR blocks
  • Client-side validation when an admin enters an allowlist or denylist of IP ranges

Edge cases

  • Addresses with leading zeros in an octet, like 192.168.001.1/24, are rejected since the alternation does not permit extra leading zeros
  • A prefix length of exactly /32 (a single host) and /0 (the entire address space) are both correctly accepted as valid boundaries
  • Whitespace around the CIDR string, such as a trailing space, causes the match to fail due to the end anchor
  • IPv4-mapped IPv6 notation (e.g. ::ffff:192.168.1.1/24) is not supported by this IPv4-only pattern

Limitations

  • Does not validate IPv6 CIDR notation; a separate pattern is needed for that format
  • Does not check whether the given prefix length is conventional for the address class or whether host bits are zeroed
  • Does not verify that the CIDR block is actually routable, allocated, or reachable
  • Very long or malformed strings with extra slashes or dots are rejected, but no partial-match diagnostics are provided

Interactive Tester

Edit the pattern or text below — matching runs live in your browser.

//
Open in Playground →
192.168.1.0/24 10.0.0.0/8 0.0.0.0/0

Test Cases

Editable — add your own inputs to see if they pass.

InputExpectedResult
Pass
Pass
Pass
Pass
Pass
Pass
Pass
Pass
Pass
Pass

Language Variants

Production-ready examples in 12 languages.

const cidrRegex = /^(?:(?:25[0-5]|2[0-4]\d|1\d\d|[1-9]?\d)\.){3}(?:25[0-5]|2[0-4]\d|1\d\d|[1-9]?\d)\/(?:3[0-2]|[12]?\d)$/;
console.log(cidrRegex.test('192.168.1.0/24')); // true

Common Mistakes

Using a naive `\d{1,3}` for each octet, which accepts out-of-range values like 999

Fix: Use a numeric-range alternation such as `25[0-5]|2[0-4]\d|1\d\d|[1-9]?\d` for each octet

Forgetting to also validate the CIDR prefix length, only checking the IP address portion

Fix: Append `\/(?:3[0-2]|[12]?\d)` to require and bound the prefix between 0 and 32

Allowing leading zeros in octets or the prefix, which some systems treat as invalid or ambiguous (e.g. octal-like 010)

Fix: Keep the range alternation as-is, since `[1-9]?\d` does not permit extra leading zeros before a nonzero digit

Performance Notes

  • The octet alternation is ordered from most specific to least specific, letting the engine short-circuit quickly on common addresses
  • Because each octet and the prefix are bounded by fixed-length alternatives, there is no unbounded repetition that could cause catastrophic backtracking
  • For validating large lists of CIDR ranges, prefer parsing with a networking library over regex once ranges need arithmetic comparison, not just syntax checking

Browser Compatibility

EngineSupportedNotes
ChromeYes—
FirefoxYes—
SafariYes—
EdgeYes—
Node.jsYes—