5 Ways to Implement Phone Number Validation in Yup

Correctly validating phone numbers in Yup ensures you get clean user data. We'll walk through five different methods, providing working code for each. You'll also see the pitfalls of these traditional approaches and how Abstract API helps address them for more dependable results.

How to Implement Phone Number Validation in Yup

Here are four common ways to validate phone numbers with Yup. Each method has a different approach, from simple regular expressions to more complex, context-aware rules.

Regex with .matches

This method relies on a single regular expression and Yup’s built-in .matches function. You can keep the pattern close to the E.164 standard to avoid the need for country-specific rules. The code imports Yup and defines a schema for a string. It marks the field as required and then uses the .matches method with a regex pattern. The pattern checks for an optional plus sign, followed by a non-zero digit, and then 9 to 14 more digits.

import * as Yup from 'yup';

const phoneSchema = Yup.string()
  .required('phone required')
  .matches(/^\+?[1-9]\d{9,14}$/, 'invalid phone');

Custom .test with libphonenumber-js

This approach uses the libphonenumber-js library, which contains the same metadata Google uses for phone number validation. With Yup’s custom .test function, you delegate the complex logic to that library. This method handles both national and international formats.

The code imports `isValidPhoneNumber` from the library and Yup. It then defines a schema that uses .test, which receives the phone number value and passes it to isValidPhoneNumber to determine its validity.

import { isValidPhoneNumber } from 'libphonenumber-js';
import * as Yup from 'yup';

const phoneSchema = Yup.string().test(
  'is-valid-e164',
  'invalid phone',
  value => isValidPhoneNumber(value || '')
);

External addMethod Plugin

Packages like yup-phone or yup-phone-lite extend Yup with a dedicated .phone() validator. These packages use Yup.addMethod behind the scenes to make the new validator available. They offer features like strict and loose validation modes and automatic country code defaults.

The code shows how to import Yup and the yup-phone package. You can then call .phone() directly on a string schema. The examples show how to set a default country, enforce strict validation, or provide a custom error message.

import * as Yup from 'yup';
import 'yup-phone';           // or 'yup-phone-lite'

const usSchema    = Yup.string().phone().required();          // defaults to US
const inStrict    = Yup.string().phone('IN', true).required();
const customError = Yup.string().phone('US', false, '${path} bad').required();

Context-aware .when Rules

You can use Yup’s .when method to bind the phone number validation rule to another field, such as a country selector. This allows you to switch validation patterns or plugins dynamically. This is useful for applications that need to handle multiple regions within a single code bundle.

The code defines an object schema with country and phone fields. The phone field’s validation depends on the country field. If the country is 'US', it applies a specific regex. Otherwise, it uses a different test function.

const schema = Yup.object({
  country: Yup.string().required(),
  phone:   Yup.string().when('country', {
    is:  'US',
    then: Yup.string().matches(/^\+1\d{10}$/, 'US phone invalid'),
    otherwise: Yup.string().test(
      'intl',
      'intl phone invalid',
      v => isValidPhoneNumber(v || '')
    )
  })
});

Challenges of Phone Number Validation in Yup

While these methods offer a starting point, they introduce significant reliability and security issues. These drawbacks often lead to data integrity problems and create maintenance burdens for development teams.

• Numbering plans change often. Plugins like yup-phone depend on bundled metadata that can become outdated. This causes the validation to reject real numbers and accept fake ones, a problem for any library-based approach.
• The yup-phone plugin conflicts with Yup’s nullable contract. It flags empty values as errors, which forces developers to write extra .when or .test logic. This adds complexity and potential edge cases.
• Validation confirms only the format. Methods that use libphonenumber cannot verify if a number is active or reachable. A syntactically correct number might not receive an SMS, which requires external verification anyway.
• All checks execute in the browser. A user can disable JavaScript or modify the schema to bypass validation. Without server-side checks, your API trusts unvalidated data and exposes fraud vectors.