Phone Number Validation: Possible, Valid, and Reachable Are Not the Same Thing

Short answer: when you ask "is this phone number valid?" you are actually asking three separate questions. Possible means the digits fit the length range of the numbering plan. Valid means the prefix matches a range a regulator has assigned. Reachable means there is a live line on that number right now, and only a network lookup can answer it. A regex answers none of the three, and a true from a validation library only means the library's dataset agrees with the prefix.

Confusing these layers produces two failure modes that look nothing alike. Numbers that pass your check and then bounce forever, and real numbers that your own form rejects. Both cost money, and both become fixable once you know which layer is failing.

What each layer actually proves

The order matters because each layer costs more than the one below it. Layer 1 is arithmetic. Layer 2 is a lookup in a file shipped inside your library. Layer 3 is a network round trip against carrier data, which is the only layer worth paying for.

Layer 1: "possible" is a length check and nothing else

Most engineers carry an assumption that a phone number is 10 digits, or 11 once you add the country code. That assumption holds for the United States and almost nowhere else. Here are the length ranges recorded in the metadata of phonenumbers 9.0.41, read directly from the library:

Mobile numbers cluster at 9 or 10 digits, but Indonesia spans 9 to 12 and the Netherlands ships both 9 and 11. The general descriptor is wider still, because it also covers service numbers, short codes and corporate ranges. Any pattern that demands a fixed digit count will reject valid numbers the moment your list leaves North America.

This is what isPossibleNumber() does. It counts digits and compares them against these ranges. Nothing about the prefix is consulted, which is why it stays fast and why it can only say "maybe".

Layer 2: "valid" is a prefix lookup against a dataset with a release date

isValidNumber() goes further and checks the prefix against ranges that the library ships as metadata. That metadata is a snapshot taken when the package was built. When a regulator assigns a new range, every installed copy keeps rejecting it until somebody upgrades.

In January 2026 a thread on the libphonenumber discussion group reported three North American area codes, 357, 837 and 679, that isValidNumber() flagged as invalid even though they had been allocated. A Google engineer replied in the same thread that the codes were assigned to their regions but not yet assigned to operators, and that anyone running metadata older than the update would see them fail.

We reproduced it on both sides before writing this, against phonenumbers 9.0.41 in Python and libphonenumber-js 1.13.15 in JavaScript:

// libphonenumber-js 1.13.15
parsePhoneNumber("+14155550123").isValid(); // true  - 415 is an old assignment
parsePhoneNumber("+13575550100").isPossible(); // true
parsePhoneNumber("+13575550100").isValid(); // false - 2025 assignment, missing from metadata

Two things follow from that table. A number can be possible and invalid at the same time, which is the whole difference between the two functions. And an invalid verdict is a statement about your dataset version, not about the number.

The most common attempted fix is switching libphonenumber-js from its default metadata to the full libphonenumber-js/max build. It does not help. We ran both. The max metadata adds precise patterns for ranges that already exist in the dataset, so it catches more malformed numbers inside known ranges. It cannot add a range the dataset never had. Upgrading the package is the only thing that clears a false negative caused by a new assignment.

Layer 3: "reachable" is the only layer that talks to the network

Layers 1 and 2 run offline against static data. Layer 3 asks the network itself whether the number is allocated, whether the line is in service, and what kind of line it is. That is the job of an HLR lookup or a carrier lookup, and it is the difference between "this number could exist" and "this number exists on a switch right now".

Line type comes from this layer: mobile, fixed, VoIP, toll-free, pager. It is the field that decides whether an SMS can arrive at all, because a fixed line cannot receive one no matter how valid its prefix is.

The leading-zero trap

National formats carry a trunk prefix in front of the number. International numbers do not. ITU-T E.164 defines the maximum length at 15 digits including the country code, and the trunk prefix is explicitly not part of the international number. Most libraries handle this for you when you parse with the right country context. Italy is the exception.

Germany, the United Kingdom and France drop the zero. Italy keeps it, because the zero belongs to the subscriber number rather than to the dialling plan. A normaliser that runs digits.replace(/^0/, "") will corrupt every Italian number it touches, and the corrupted value will often still pass a length check afterwards.

Where a regex is the right tool, and where it is not

Regex is useful in exactly one place: cheap input hygiene. It can strip brackets and dashes, catch an obvious typo before a request is sent, and keep junk out of your database. What it cannot do is decide whether a number is real, because that answer does not exist in the string.

Which layer does your use case actually need

What none of these layers can tell you

Layer 3 tells you a line exists. It does not tell you who uses it, whether they want your message, or whether they will answer a call. Push any of these tools past that line and you are guessing.

Number types also move. A fixed line can become a VoIP line after porting, and number portability means the range data that originally described a block does not always describe the network serving it today. A type field is a strong hint with a real error rate, not a fact about the future.

The practical consequence for your logs: record the library version and the lookup timestamp next to every result. When a number you validated six months ago now fails, you need to know whether the number changed or your data did.

Our own API sits at layer 3. It reads allocation, line type and reachability from carrier data, and it returns a reason code for each verdict. It cannot repair a number that was typed wrong, and it cannot tell you whether the person behind the line will respond. Anyone selling you that answer is selling you something else.

Running this in bulk

The ordering that survives real data is: normalise everything to E.164 first, run layer 2 locally to shrink the list, then send only the survivors to a network lookup. Doing it in that order means you pay for layer 3 only on numbers that already passed the free checks.

For a single number, the free phone validator runs all three layers and returns the line type alongside the verdict. For lists, bulk validation methods compared walks through the ordering and the cost trade-offs, the carrier lookup API and HLR lookup API pages document the layer 3 endpoints, and the carrier data guide explains what each returned field means before you route on it.

FAQ

Why does isValidNumber() return false for a real phone number?

Usually because the library's metadata predates the range. New area codes, reopened ranges and new mobile prefixes are rejected until the package is upgraded. In January 2026 three North American codes, 357, 837 and 679, were still failing on current installs, and switching to larger metadata builds did not fix it. Upgrade the library, and log its version next to each result so stale data is visible instead of silent.

Is a regex enough to validate a phone number?

No. A regex can confirm that a string looks like a phone number and strip formatting. It cannot know which prefixes a country has assigned, and it cannot know whether a line exists. Every pattern strict enough to be useful will also reject real numbers from open numbering plans such as Germany or Japan.

What is the difference between isPossibleNumber and isValidNumber?

isPossibleNumber() compares the digit count against the length range for that country. isValidNumber() also checks the prefix against assigned ranges. A number can be possible and invalid at the same time, which is exactly what happens to a correctly shaped number carrying an unassigned area code.

How long can an international phone number be?

ITU-T E.164 caps an international number at 15 digits including the country code. The national part is shorter and its length depends on the country: 9 or 10 digits for most mobile numbers, 8 in Singapore, up to 12 in Indonesia. That is why you cannot validate a national number on digit count alone.

Why do some countries keep a leading zero and others drop it?

The leading zero is a national trunk prefix, and the trunk prefix is not part of the international number. Most countries drop it when converting to E.164. Italy keeps it because the zero belongs to the subscriber number itself. This is why hard-coded zero-stripping damages Italian data while leaving the value looking plausible.

Does phone number validation tell you anything about messaging apps?

No. Messaging presence is a separate check against each platform, and the answer changes from week to week as accounts are created and deleted. Validation answers whether the line exists and what type it is. Those are different questions with different sources, and a tool that claims both in one call is usually bolting two systems together.

Related

• How to validate phone numbers in bulk: methods compared
• How to find a phone number's carrier
• Phone number validation, step by step
• E.164 phone number format