5 Ways to Validate Phone Numbers in C#

Phone number validation is a standard step for maintaining data integrity in C# applications. Five distinct methods, complete with code snippets, can handle this task. The discussion also covers the pitfalls of these traditional techniques and shows how Abstract API solves these common problems.

How to Validate Phone Numbers in C#

C# offers several ways to check phone numbers for correctness. These methods range from simple pattern matches to comprehensive library functions that handle complex international and regional rules.

Regular Expression

A raw regular expression, or regex, provides a fast way to block malformed input when you know the accepted format. A single line of code can be injected anywhere in your application. The compiled flag makes it negligible at run time after the first match. You can extend this method with a chain of multiple patterns or use a switch on the detected country.

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

System.ComponentModel.DataAnnotations

ASP.NET Core’s model-binding pipeline can reject bad numbers declaratively. The MVC filter executes the attributes automatically, so no special code is needed in controllers or APIs. You can combine the `[Phone]` attribute, which offers a coarse sanity check, with a stricter `[RegularExpression]` or a custom ValidationAttribute when regional rules matter.

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

libphonenumber-csharp

This method uses a NuGet package ported from Google's library. It is important to keep the package updated, as the metadata behind the `IsValidNumber` function changes frequently. The library knows national and international formats for over 200 regions. It also normalizes numbers and detects their type, such as mobile or toll-free.

The code uses the `PhoneNumberUtil` class to parse and validate the number. The `Parse` method throws an exception on syntax errors, while `IsValidNumber` performs structural and metadata checks.

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
}

GlobalPhone

GlobalPhone is a lighter wrapper around the same metadata as libphonenumber but with a simpler API. The `Parse` method returns null on bad input. This approach allows for a one-liner check that will not throw an exception.

It is a good choice when you only need to validate or normalize a number without the full `PhoneNumberUtil` surface.

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#

Traditional validation methods in C# present several obstacles. These techniques often struggle with the dynamic nature of global phone networks, which leads to unreliable results and maintenance overhead for developers.

• Numbering plans constantly change with new prefixes and variable lengths. This reality makes any custom Regular Expression outdated almost as soon as it is deployed. Maintenance becomes a continuous and difficult task for developers to manage.
• The System.ComponentModel.DataAnnotations.PhoneAttribute only confirms phone-like characters. It ignores country context, length limits, and reserved number ranges. This superficial check leads to both false positives and missed errors in a production environment.
• Libraries like libphonenumber-csharp and GlobalPhone rely on static metadata. Since regulators publish updates with a delay, the data can be stale. A structurally valid number does not guarantee it is assigned or reachable.
• User input formats are ambiguous and inconsistent. People submit local numbers with trunk zeros, vanity text, or extensions. This variety makes it difficult to normalize a number into a single, reliable canonical string like E.164.