IPv4 Private Address Ranges Regex for JavaScript
/^(?:10\.(?:(?:25[0-5]|2[0-4][0-9]|1[0-9]{2}|[1-9][0-9]|[0-9])\.){2}(?:25[0-5]|2[0-4][0-9]|1[0-9]{2}|[1-9][0-9]|[0-9])|172\.(?:1[6-9]|2[0-9]|3[01])\.(?:25[0-5]|2[0-4][0-9]|1[0-9]{2}|[1-9][0-9]|[0-9])\.(?:25[0-5]|2[0-4][0-9]|1[0-9]{2}|[1-9][0-9]|[0-9])|192\.168\.(?:25[0-5]|2[0-4][0-9]|1[0-9]{2}|[1-9][0-9]|[0-9])\.(?:25[0-5]|2[0-4][0-9]|1[0-9]{2}|[1-9][0-9]|[0-9]))$/What this pattern does
This page provides a comprehensive, battle-tested regular expression for matching ipv4 private address ranges, ported and verified for JavaScript. A rigorously tested regex reduces debugging time and protects your application from edge-case failures. The snippet below is ready to drop into your JavaScript project — whether you're validating in an Express middleware, a Next.js API route, or a client-side form.
Javascript Implementation
// IPv4 Private Address Ranges
// ReDoS-safe | RegexVault — Web & Network > IPv4
const ipv4PrivateAddressRangesRegex = /^(?:10\.(?:(?:25[0-5]|2[0-4][0-9]|1[0-9]{2}|[1-9][0-9]|[0-9])\.){2}(?:25[0-5]|2[0-4][0-9]|1[0-9]{2}|[1-9][0-9]|[0-9])|172\.(?:1[6-9]|2[0-9]|3[01])\.(?:25[0-5]|2[0-4][0-9]|1[0-9]{2}|[1-9][0-9]|[0-9])\.(?:25[0-5]|2[0-4][0-9]|1[0-9]{2}|[1-9][0-9]|[0-9])|192\.168\.(?:25[0-5]|2[0-4][0-9]|1[0-9]{2}|[1-9][0-9]|[0-9])\.(?:25[0-5]|2[0-4][0-9]|1[0-9]{2}|[1-9][0-9]|[0-9]))$/;
function validateIpv4PrivateAddressRanges(input: string): boolean {
return ipv4PrivateAddressRangesRegex.test(input);
}
// Example
console.log(validateIpv4PrivateAddressRanges("10.0.0.1")); // trueTest Cases
Matches (Valid) | Rejects (Invalid) |
|---|---|
10.0.0.1 | 11.0.0.1 |
10.255.255.255 | 172.15.0.1 |
172.16.0.1 | 172.32.0.1 |
172.31.255.255 | 192.169.0.1 |
192.168.0.1 | 8.8.8.8 |
When to use this pattern
This pattern is drawn from the Web & Network > IPv4 category and carries a ReDoS-safe certification. That matters for JavaScript developers because especially critical in long-running Node.js event loops where a ReDoS vulnerability can block the entire process. RegexVault audits patterns against known backtracking attack vectors, ensuring you have the necessary context before using this regex in a high-stakes production environment.
Common Pitfalls
172.16–31 is commonly written incorrectly as 172.(16-31) or 172.1[6-9|2[0-9]|31 — missing the 30 or mishandling the range.
Technical Notes
172.x range uses 1[6-9]|2[0-9]|3[01] to cover exactly 16–31. Three distinct top-level alternations for each private block — no shared suffix, which prevents backtracking.
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