IPv4 Address (Strict 0–255) Regex for JavaScript
/^(?:(?:25[0-5]|2[0-4][0-9]|1[0-9]{2}|[1-9][0-9]|[0-9])\.){3}(?:25[0-5]|2[0-4][0-9]|1[0-9]{2}|[1-9][0-9]|[0-9])$/What this pattern does
Need to validate IPv4 addresses with exacting precision in your JavaScript project? This regex, designed for strict 0–255 octet validation, is your solution. It ensures that only properly formatted IP addresses are accepted, preventing malformed data from reaching your application. You can integrate this regex directly into your JavaScript code for form validation, API input sanitization, or network configuration checks.
Javascript Implementation
// IPv4 Address (Strict 0–255)
// ReDoS-safe | RegexVault — Web & Network > IPv4
const ipv4AddressStrict0255Regex = /^(?:(?:25[0-5]|2[0-4][0-9]|1[0-9]{2}|[1-9][0-9]|[0-9])\.){3}(?:25[0-5]|2[0-4][0-9]|1[0-9]{2}|[1-9][0-9]|[0-9])$/;
function validateIpv4AddressStrict0255(input: string): boolean {
return ipv4AddressStrict0255Regex.test(input);
}
// Example
console.log(validateIpv4AddressStrict0255("0.0.0.0")); // trueTest Cases
Matches (Valid) | Rejects (Invalid) |
|---|---|
0.0.0.0 | 256.1.1.1 |
192.168.1.1 | 192.168.1 |
255.255.255.255 | 192.168.1.1.1 |
10.0.0.1 | 192.168.01.1 |
172.16.254.1 | not.an.ip.addr |
When to use this pattern
In JavaScript, poorly constructed regular expressions can lead to severe performance issues, especially when processing user-provided data. This is particularly concerning in server-side JavaScript environments like Node.js, where a ReDoS attack could potentially exhaust server resources. Using a ReDoS-safe pattern here guards against this risk. With this vetted regex, you'll be able to confidently deploy in production, knowing that your application is protected against malicious input crafted to exploit regex backtracking vulnerabilities.
Common Pitfalls
Using \d{1,3} instead of the strict alternation allows values like 999 or 256. Do not use [0-9]{1,3} — it accepts out-of-range octets.
Technical Notes
The alternation order in each octet group (25[0-5] first, then 2[0-4], then 1xx, then [1-9][0-9], then single digit) is critical for correctness. Reordering breaks range enforcement. Leading zeros are rejected because 01 does not match any branch.
Have a pattern that belongs in the vault?
Submit it for review — community-verified patterns get credited to your GitHub handle. Free submissions join the queue. Priority review available for $15.
Submit a Pattern