DEV Community: A A

A valid phone number is not necessarily a usable phone number

A A — Wed, 07 Oct 2026 14:18:24 +0000

A valid phone number is not necessarily a usable phone number

Most applications treat phone number validation as a boolean:

js if (isValidPhoneNumber(number)) { // good to go }

That is useful, but it answers a much narrower question than it looks like it does.

A number can be perfectly valid according to a country's numbering plan and still be the wrong kind of number for what your application is about to do.

If you are building OTPs, SMS notifications, account recovery, fraud checks or outbound calling, it helps to think of phone validation as several separate layers.

Layer 1: can the number be parsed?

The first problem is simply turning whatever the user typed into a consistent format.

These could all represent the same UK number:

07400 123456
07400123456
+44 7400 123456
0044 7400 123456

Internally, you generally want to reduce that to E.164:

+447400123456

Libraries such as libphonenumber-js handle most of this for you.

import parsePhoneNumber from "libphonenumber-js/max";

function normalizePhone(input, defaultCountry) {
  const phone = parsePhoneNumber(input, defaultCountry);

  if (!phone || !phone.isValid()) {
    return null;
  }

  return {
    e164: phone.number,
    country: phone.country
  };
}

This gets you a normalized number and checks it against numbering-plan metadata.

But it still does not tell you very much about the actual line.

Layer 2: is it valid according to the numbering plan?

This is the distinction that often gets lost.

A phone-number library can usually tell you things such as:

+447400123456

Does the length make sense?
Does the prefix fit the country's numbering plan?
Can it be normalized?
Which country does it appear to belong to?

That is static validation.

It does not mean somebody currently owns the number.

It also does not automatically mean the number can receive an SMS.

And it does not necessarily tell you which network serves it today.

For plenty of applications, static validation is enough. A contact form probably does not need much more.

An authentication system probably does.

Layer 3: what type of line is it?

Suppose two numbers both pass your validation library.

One is a mobile number.

The other is a fixed line.

From the point of view of isValid(), both may be completely legitimate phone numbers.

From the point of view of an SMS workflow, they are very different.

This is where line-type information becomes useful:

{
  "number": "+447400123456",
  "valid": true,
  "line_type": "mobile"
}

Typical classifications include:

mobile
fixed_line
voip
toll_free
premium_rate

The important part is not the label itself. It is what your application does with it.

For example:

switch (lookup.lineType) {
  case "mobile":
    return sendSms();

  case "fixed_line":
    return askForAnotherNumber();

  default:
    return applyYourOwnRules();
}

That is a much better model than treating every syntactically valid number identically.

Layer 4: which network is it actually on?

There is another complication: number portability.

Someone can start with one mobile operator and later move their number to another.

The phone number does not change.

That means the prefix can tell you something about how a number was originally allocated, but it should not automatically be treated as the current carrier.

So there are really two different pieces of information:

numbering-plan information
current network information

They come from different places.

A static library is extremely useful for the first.

Current carrier information normally requires a lookup against telecom data.

This distinction matters whenever your application makes decisions based on the serving network rather than merely formatting the number.

Validation is still not reachability

There is one final distinction worth keeping in mind.

Even after you know:

valid: true
line_type: mobile
carrier: Example Mobile

you still have not mathematically proven that your next SMS will be delivered.

Phones can be switched off. Accounts can be suspended. Networks can reject traffic. Numbers can change state.

So I find it useful to keep these concepts separate:

syntax
    ↓
numbering-plan validity
    ↓
line type
    ↓
current carrier
    ↓
reachability / delivery

Each layer answers a different question.

Trying to compress all of them into a single field called valid usually creates bad assumptions elsewhere in the system.

Design the API around the decision

Instead of returning this:

{
  "valid": true
}

I prefer responses that expose why the application should make a decision:

{
  "normalized": "+447400123456",
  "valid": true,
  "country": "GB",
  "line_type": "mobile",
  "carrier": "Example Mobile",
  "ported": true
}

Then your business logic stays explicit.

Your signup service might care about line_type.

Your routing service might care about carrier.

Your fraud system might care about portability or other risk signals.

Your address book might only care that the number was normalized successfully.

There is no universal definition of a "good phone number". It depends on what you are about to do with it.

Where I ran into this

Disclosure: I work on Carrier Reveal, which provides carrier, line-type and portability information for phone numbers.

Building around this problem made me realize that the mistake is usually not bad phone-number validation. It is asking one validation step to answer questions it was never designed to answer.

A library such as libphonenumber is very good at understanding telephone numbering plans.

Use it for that.

Then add live data only when your application actually needs to know something about the number as it exists today.

What a phone number tells you before you send an SMS

A A — Sat, 03 Oct 2026 16:56:03 +0000

If you send an SMS to a landline it disappears. No bounce, no error you can act on, and you are still billed for it. The same goes for a disconnected number and for plenty of VoIP numbers. The fix is to find out what a number actually is before you send to it.

Here is what a phone number can tell you, and what it cannot.

Start by normalizing to E.164
Before anything else, get the number into E.164: a plus sign, the country code, then the national number, with no spaces, dashes or brackets.

07400 123456 -> +447400123456
(202) 555-0143 -> +12025550143
Two things go wrong at this step.

First, a national number with no country code is ambiguous. 07400123456 is a UK mobile, but a bare 7400123456 could belong to several countries. You need a default country to parse against, usually the country of the account that submitted the number.

Second, people paste extensions, letters and stray leading zeros. Anything that fails to parse should stop here rather than being sent anywhere downstream.

Line type is the decision you actually care about
Once you have a valid E.164 number, the useful question is what kind of line it is.

mobile: can receive SMS

fixed_line: cannot receive SMS in most countries

voip: sometimes can, often cannot, and a meaningful fraud signal at signup

toll_free, premium_rate, pager: do not send

A validation library on its own will not tell you this reliably. Number ranges are allocated by type, so a library that knows only the allocation table tells you what the range was issued as, not what the number is today.

Portability is why the allocated range is not enough
Most countries let a subscriber keep their number when they switch network. That is mobile number portability, and it means the carrier that was allocated a range is often no longer the carrier serving a given number in it.

If you route SMS by allocated range in a country with portability, you pay the wrong carrier's rate and your delivery rate quietly drops. Getting the current network needs a live lookup, not a static table.

What a lookup gives you back
A useful response is more than valid: true. A real one looks like this:

{
"input_phone": "+447400123456",
"normalized_e164": "+447400123456",
"valid": true,
"country": "GB",
"country_name": "United Kingdom",
"region": "Europe",
"line_type": "mobile",
"carrier": "EE",
"sms_ready": true,
"call_ready": true,
"reason": "valid_mobile",
"cached": false,
"checked_at": "2026-06-30T10:04:11.204Z",
"credits_debited": 1
}
The fields worth building logic on:

valid together with reason, so you know why a number failed and not just that it did

line_type, the routing decision

carrier, the current network after portability

sms_ready and call_ready, if you would rather not write that logic yourself

cached, so you can tell a fresh lookup from a cached one

Three places the check pays for itself
At signup. Reject a number that cannot receive your OTP before the user presses send, instead of after they wait for a code that was never going to arrive.

Before a campaign. Split the list on sms_ready and suppress the rest. You pay per message either way.

Before a dialler run. call_ready and line_type keep agents off numbers that will not connect.

Cache, and deduplicate first
Lookups cost money per number, so cache them. The network a number sits on does not change often, and a 24 hour cache absorbs most repeat traffic in practice.

Deduplicate inside a batch before you send it, too. The same number turns up several times in one CSV more often than you would expect, and each copy would otherwise be a separate paid lookup.

Trying it
Disclosure: this is our own product. We built Carrier Reveal around exactly this, so treat the example below as one implementation rather than a recommendation. The API is one POST per number, or up to 100 in a batch:

curl -X POST https://api.phonelistcleaner.com/v1/lookup \
-H "Authorization: Bearer plc_" \
-H "Content-Type: application/json" \
-d '{"phone":"+447400123456","defaultCountry":"GB"}'
The docs are at Carrier Lookup API | Carrier Reveal. Twilio Lookup and Numverify solve the same problem if you would rather use something you already have.

The general point holds whatever you use: normalize first, check the line type, and never trust the allocated range in a country with number portability.