5 Ways to Implement Phone Number Validation in Java

Phone number validation is a fundamental step for ensuring data integrity in Java applications. We'll walk through four distinct methods for validation, providing code for each. Then, we'll look at the common drawbacks of these approaches and demonstrate how Abstract API overcomes them.

How to Implement Phone Number Validation in Java

We explore three distinct techniques for phone number validation in Java. Each method offers a different approach to confirm the structural correctness of a phone number.

Regular Expressions and java.util.regex.Pattern

This approach represents the most direct solution. You compile a pattern once when the application starts and then reuse it for subsequent validations, which improves performance.

The provided code defines two patterns. The first aligns with the E.164 specification, and the second accommodates the common North-American 10-digit format. The "isValid" method returns true if the input string matches either pattern. More complex expressions can also handle optional country codes and various separators, as shown in other examples. You can find additional patterns for E.123 and E.164 formats.

private static final Pattern E164 =
        Pattern.compile("^\\+\\d{1,3}\\s?\\d{1,14}$");   // ITU E-164
private static final Pattern US_LOCAL =
        Pattern.compile("^(\\+1\\s?)?((\\(\\d{3}\\))|\\d{3})[- .]?\\d{3}[- .]?\\d{4}$");

boolean isValid(String raw) {
    return E164.matcher(raw).matches() || US_LOCAL.matcher(raw).matches();
}

Google's libphonenumber

Google's libphonenumber library contains metadata for every telephone numbering plan in the world. It provides semantic validation that goes beyond simple checks for length and prefixes. To use it, you first add the dependency to your project build file.

The "PhoneNumberUtil" class is the main entry point. You parse a raw string with a region hint, like "US". The "isPossibleNumber" method checks length and format, while "isValidNumber" enforces region-specific rules. You can also format the number into the standard E.164 format.

<!-- Maven -->
<dependency>
  <groupId>com.googlecode.libphonenumber</groupId>
  <artifactId>libphonenumber</artifactId>
  <version>8.13.34</version>
</dependency>

PhoneNumberUtil util = PhoneNumberUtil.getInstance();
Phonenumber.PhoneNumber num = util.parse(raw, "US");     // region hint
boolean syntaxOk  = util.isPossibleNumber(num);          // length/format
boolean valid     = util.isValidNumber(num);             // national rules
String e164       = util.format(num, PhoneNumberUtil.PhoneNumberFormat.E164);

Jakarta Bean Validation Custom Constraint

If your project already uses a Jakarta-EE stack, such as Hibernate Validator, you can create a custom constraint. This technique wraps a validation strategy, like libphonenumber, so that validation occurs automatically on your data objects.

You define a custom annotation, like "@Phone", and an associated validator class. The "PhoneValidator" class implements the "ConstraintValidator" interface and contains the logic to check the phone number. By annotating fields with "@Phone", the validation layer blocks invalid data before it can reach your business logic. A similar design can be found in a Twilio tutorial.

@Target({ FIELD, PARAMETER })
@Retention(RUNTIME)
@Constraint(validatedBy = PhoneValidator.class)
public @interface Phone { String message() default "invalid phone"; }

public final class PhoneValidator implements ConstraintValidator<Phone,String> {
    private static final PhoneNumberUtil UTIL = PhoneNumberUtil.getInstance();
    public boolean isValid(String raw, ConstraintValidatorContext ctx) {
        try {
            return UTIL.isValidNumber(UTIL.parse(raw, "US"));
        } catch (NumberParseException e) { return false; }
    }
}

Challenges of Phone Number Validation in Java

These validation methods present several operational difficulties. The structural complexity of global phone numbers and the constant evolution of numbering plans create significant hurdles for developers who rely on static rules or libraries.

• International numbering plans have complex rules. A single regex pattern often fails to cover all country-specific prefixes and length variations. Even comprehensive libraries like libphonenumber can miss edge cases due to this complexity, which requires large metadata files.
• Numbering plan metadata quickly becomes stale. New area codes and reallocated ranges appear constantly. Libraries like libphonenumber acknowledge a delay before updates arrive, so a number that validates today might fail validation tomorrow after a plan change.
• Validation only confirms a number's format, not its reachability. Methods like regex or libphonenumber cannot determine if a line is active or assigned. This creates a false sense of security about the number's operational status.
• The validation heuristics in libraries like libphonenumber are often too broad. For example, "possible length" ranges are deliberately wide, which means clearly invalid input can pass through initial checks unless you add extra, more specific logic.