5 Ways to Validate Phone Numbers with Regex

Validating phone numbers with regular expressions is a common first step in ensuring data quality for user-facing applications. We will explore five ways to implement this validation using regex, complete with working code snippets. We'll also examine the pitfalls of these traditional approaches and see how Abstract API provides a more reliable solution.

How to Implement Phone Number Validation in Regex

Regular expressions offer a direct way to check phone number formats. Here are four common regex-based methods to validate phone numbers, each with a distinct approach and code sample.

E.164-Only Validation

This method validates against the international E.164 standard. The pattern requires a number to start with a plus sign, followed by a non-zero digit, and then up to fourteen more digits. This approach works for any country because it checks the standard format, not a local one. A common version of this pattern appears on Stack Overflow.

e164 = re.compile(r'^\+[1-9]\d{1,14}$')
if e164.fullmatch(raw): …

Free-Form International Validation

This complex pattern accommodates many international formats. It supports an optional country code of one to three digits, an optional trunk '1', and various separators like spaces, dots, or hyphens. It also allows parentheses around the area code and accepts variable subscriber lengths. This type of expression is available in phone regex generators.

const intl = new RegExp(String.raw`^(\+\d{1,3}( )?)?1?\-?\.?\s?((\(\d{1,6}\))|\d{1,6})[- .]?\d{3,6}[- .]?\d{4,8}$`);
if (intl.test(raw)) { … }

Strict NANP Validation

This regex is tailored for the North American Numbering Plan (NANP), which covers the US and Canada. It looks for an optional "+1" prefix. The pattern ensures the three-digit area code does not start with a 0 or 1. It also uses alternation to accept area codes with or without parentheses, enforcing a total of ten digits. A similar US pattern appears in this reference table.

reNANP := regexp.MustCompile(`^(?:\+1\s?)?(?:\([2-9]\d{2}\)|[2-9]\d{2})[\s.-]?\d{3}[\s.-]?\d{4}$`)
reNANP.MatchString(raw)

Two-Pass Normalization and Validation

This technique involves two steps. First, a regex expression cleans the input string by the removal of any character that is not a digit, but it preserves a plus sign at the start of the string. This creates a canonical version of the number.

The second step applies business rules to the clean string. For example, the code can check if the number matches the E.164 format or a 10-digit NANP structure. This method works well when applications must store numbers in a single format but allow users to enter them in various ways.

# Step 1: Normalize
clean = re.sub(r'(?!^\+)[^\p{Nd}]', '', raw, flags=re.U)

# Step 2: Validate
if clean.startswith('+'):
    ok = bool(re.fullmatch(r'\+[1-9]\d{1,14}', clean))
elif len(clean) == 10 and clean[0] in '23456789':
    ok = True
else:
    ok = False

Challenges of Regex Phone Number Validation

While regex provides a quick filter, it presents significant limitations for robust validation. These patterns fail to account for the complexities and constant evolution of global phone number systems.

• National numbering plans constantly change with prefix splits and length expansions. This makes hard-coded patterns like the Strict NANP method age out quickly, which causes them to reject or misclassify valid numbers.
• Regex only confirms a number's format, not its real-world status. A string can match the Free-form international pattern perfectly yet correspond to an unassigned, retired, or reserved block of numbers.
• Real-world input contains optional trunk digits, carrier codes, and various separators. A single comprehensive expression, like the Free-form international one, becomes unwieldy and fragile when it tries to account for this noise.
• The E.164-only rule is too strict for common domestic formats. The two-pass normalization method hides complexity, where logic bugs in the second step can still accept invalid numbers.