5 Methods for Phone Number Validation in Laravel

Validating phone numbers is a common requirement for maintaining data quality in any Laravel application. We will explore five methods for implementation, providing working code snippets for each. Along the way, we'll examine the drawbacks of these approaches and how Abstract API can overcome them.

Laravel Phone Number Validation Methods

Here are four common approaches to phone number validation in a Laravel application, from a simple regular expression to the use of a dedicated community package.

Built-in Validator with a Regular Expression

Laravel's validator allows the use of regular expressions for custom rules. This approach defines a pattern that the input phone number must match to pass validation.

The code specifies a rule for a 'phone' field. The regex pattern checks for an E.164 format, which starts with an optional '+' sign, a country code, and then 1 to 14 additional digits.

rules():
    return [
        'phone' => [
            'required',
            // + country code, then 1-14 digits (E.164 hard limit is 15)
            'regex:/^\\+?[1-9]\\d{1,14}$/'
        ],
    ];

A Dedicated Rule Object

A more structured approach involves the creation of a dedicated Rule object. You can generate this file with the `php artisan make:rule ValidPhone` command. This encapsulates the validation logic into a reusable class.

The `ValidPhone` class implements Laravel's `Rule` interface and uses the `libphonenumber` library. The `passes` method attempts to parse the number against a specified region, like 'US', and returns true if the library considers it valid.

// In app/Rules/ValidPhone.php
class ValidPhone implements Rule
{
    public function __construct(private string $region = 'US') {}

    public function passes($attribute, $value): bool
    {
        $u = \libphonenumber\PhoneNumberUtil::getInstance();
        try {
            $p = $u->parse($value, $this->region);
            return $u->isValidNumber($p);
        } catch (\libphonenumber\NumberParseException) {
            return false;
        }
    }

    public function message(): string
    {
        return 'Invalid phone number for region '.$this->region.'.';
    }
}

// Usage in a FormRequest
'phone' => ['required', new ValidPhone('US')];

A Global Validator Macro

For application-wide reuse, you can define a global validator macro. This is typically done within the `boot` method of a service provider, such as the `AppServiceProvider`.

This approach extends Laravel's `Validator` facade with a new rule, here named `phone_global`. The rule's logic uses `libphonenumber` and becomes available anywhere in your app. You can pass parameters like the region code directly in the validation rule string.

// In AppServiceProvider::boot()
Validator::extend('phone_global', function ($attribute, $value, $parameters) {
    $region = $parameters[0] ?? null;
    $u = \libphonenumber\PhoneNumberUtil::getInstance();
    try {
        return $u->isValidNumber($u->parse($value, $region));
    } catch (\Throwable) {
        return false;
    }
});

// Usage in a FormRequest
'phone' => 'required|phone_global:US';

The Propaganistas/Laravel-Phone Package

A popular option is to use a pre-built, community-maintained package. The `propaganistas/laravel-phone` package is a well-regarded choice that you install with Composer.

This package provides a `phone` validation rule that builds upon `libphonenumber`. It offers features like multi-country validation, automatic country detection, attribute casting, and formatting helpers.

// Install with Composer
composer require propaganistas/laravel-phone

// Usage in a FormRequest
'phone' => 'required|phone:US,CA',
// or dynamic: 'phone' => (new \Propaganistas\LaravelPhone\Rules\Phone)->country(['US','CA'])

Challenges of Laravel Phone Number Validation

While these methods seem straightforward, they introduce significant reliability and security issues. Each approach presents unique drawbacks that can compromise data integrity and application stability.

• Methods that rely on libphonenumber, like a Rule object or global macro, require constant metadata updates. Without them, changes in global numbering plans and number portability lead to false positives or negatives.
• The propaganistas/laravel-phone package can be fragile. Minor updates sometimes introduce uncaught errors or cause the validator to ignore rules like nullable, which can crash a request instead of return a simple validation error.
• All methods, from a simple regex to a dedicated package, only check format. They cannot confirm a number is active or prevent the use of disposable numbers, which leaves applications open to bot sign-ups and fraud.
• Model-level casts from the propaganistas/laravel-phone package create brittle code. An incorrect field assignment order during mass updates can trigger exceptions before the validator even runs, which makes the entire flow fragile.