5 Ways to Validate Phone Numbers in C#

Ensuring phone numbers are valid is a key step in C# development for maintaining data integrity. We will explore five different methods for phone number validation, complete with working code snippets. We'll also examine the common pitfalls of these approaches and see how Abstract API addresses these issues.

How to Implement Phone Number Validation in C#

Here are four distinct methods to validate phone numbers in your C# applications. Each approach comes with a detailed explanation and a functional code snippet for implementation.

Validation with a Regular Expression

A raw regex offers the quickest way to block malformed input when you know the accepted formats. A single line of code can be placed anywhere, such as in a controller or a value-object factory. The "compiled" flag makes its run-time performance cost negligible after the first match.

You can extend this method through a chain of multiple patterns or with a switch on the detected country. The code below shows an example for an Australian phone number.

string pattern = @"^([\+]?61[-]?|0)?[1-9][0-9]{8}$";   // AU example
bool ok = Regex.IsMatch(input, pattern, RegexOptions.Compiled | RegexOptions.CultureInvariant);

Validation with System.ComponentModel.DataAnnotations

The model-binding pipeline in ASP.NET Core can reject incorrect numbers in a declarative way. You can use attributes like the "[Phone]" attribute for a coarse sanity check. For stricter validation, you can combine it with a "[RegularExpression]" attribute or a custom "ValidationAttribute".

The MVC filter executes these attributes automatically. This means no special code is necessary inside controllers or APIs to trigger the validation logic.

public sealed class Customer
{
    [Required]
    [Phone]                 // coarse sanity check
    [RegularExpression(@"^\+?[1-9]\d{1,14}$")] // E.164 override
    public string Phone { get; init; }
}

Validation with libphonenumber-csharp

This method requires the addition of the libphonenumber-csharp NuGet package to your project. The library possesses knowledge of national and international formats for more than 200 regions. It can also normalize numbers, detect the number type, and format the number as a user types.

The core of the validation logic involves the "PhoneNumberUtil" class. You first parse the raw string with a region code. Then, you check if the parsed number is valid. The parse operation throws an exception on syntax errors.

using PhoneNumbers;

static bool IsValid(string raw, string region)
{
    var util = PhoneNumberUtil.GetInstance();
    var parsed = util.Parse(raw, region);      // throws on syntax errors
    return util.IsValidNumber(parsed);         // structural + metadata checks
}

Validation with GlobalPhone

GlobalPhone is a lighter wrapper with a simpler API. The API returns null on bad input, which gives you a one-liner that will not throw an exception unless you explicitly ask it to. This makes it a good choice when you only need to confirm validity or normalize a number.

using GlobalPhone;

var n = GlobalPhone.Parse("+1-312-555-1212");
bool ok = n?.IsValid ?? false;
string e164 = n?.InternationalString;

Challenges of Phone Number Validation in C#

The methods discussed present their own set of trade-offs. These approaches often fall short in real-world scenarios due to several persistent issues with phone number data and formats.

• Numbering plans change constantly with new prefixes and shifting area codes. This makes any regular expression or custom rule set outdated almost as soon as it is deployed, which leads to validation failures.
• The [Phone] attribute in System.ComponentModel.DataAnnotations only confirms the presence of phone-like characters. It ignores country context, length limits, and reserved number ranges, which results in both false positives and missed errors.
• Libraries like libphonenumber-csharp and GlobalPhone rely on static metadata. This data lags behind official updates from regulators and cannot confirm if a number is currently assigned or ported, so a structurally valid number may not be reachable.
• User input is often ambiguous. People paste local numbers with trunk zeros, vanity text, or extensions. This makes it difficult to reliably convert a number into a standard format like E.164 for consistent validation.