IPv4 Address (Strict 0–255) Regex for Go
/^(?:(?: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 Go application? This page offers a robust regular expression solution, specifically designed to match IPv4 addresses and ensure each octet falls within the 0–255 range. This regex will reject invalid formats and out-of-range values, making it ideal for network configuration tools or any Go project requiring strict IPv4 address validation. Employ it directly in your Go code, whether you are building a CLI, a web server, or a data processing pipeline.
Go Implementation
// IPv4 Address (Strict 0–255)
// ReDoS-safe | RegexVault — Web & Network > IPv4
package validation
import "regexp"
var ipv4AddressStrict0255Re = regexp.MustCompile(`^(?:(?: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])$`)
func ValidateIpv4AddressStrict0255(s string) bool {
return ipv4AddressStrict0255Re.MatchString(s)
}
// Example
// fmt.Println(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
Go's RE2 engine prevents catastrophic backtracking, so this pattern is already safe from a ReDoS perspective. However, using a verified pattern is still crucial. A carefully constructed regex minimizes the risk of unexpected behavior or performance degradation, especially with complex validation tasks. Imagine you're building a network monitoring tool in Go; using this verified pattern ensures that your application reliably parses and validates IPv4 addresses under heavy load, making it production-ready.
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