E.164 and phone number validation: formatting, MSISDN normalization, and why it matters for delivery.

E.164 is the ITU-T standard for writing phone numbers for international use: a leading plus sign, a one-to-three-digit country code, and the national number, with no separators and at most 15 digits. Storing each number in this canonical form — the MSISDN a network routes to — is what makes validation and reliable delivery possible.

What E.164 is: the international numbering plan

E.164 is ITU-T Recommendation E.164, the international public telecommunication numbering plan. It gives every phone on the planet a single, globally unique address so that a call or message can be routed from any network to any other. An E.164 number has three parts: a country code (CC) of one to three digits, a national destination code (NDC, often the operator or area code), and the subscriber number. Written together they must not exceed 15 digits.

The canonical string is a leading '+' followed by digits only — for example +971500000000. The '+' is a placeholder for whatever international access prefix the originating network uses (00 in most of the world, 011 in North America); storing the '+' instead of a country-specific prefix is precisely what keeps the number portable between networks and countries. There are no spaces, dashes, parentheses, or leading zeros inside an E.164 number: those are display conventions, not part of the number.

MSISDN: the number the network actually routes to

MSISDN stands for Mobile Station International Subscriber Directory Number — the dialable E.164 number that identifies a mobile subscriber. It is what you store, dial, and send an SMS to. It is deliberately separate from the IMSI, the identity held on the SIM under ITU-T E.212 (a mobile country code plus mobile network code plus subscriber identity). The operator's Home Location Register maps an MSISDN to its current IMSI and serving network, which is how a message addressed to an E.164 number reaches the right handset even after the subscriber roams or ports.

The practical takeaway: an MSISDN is just an E.164 number for a mobile line. When people say 'normalize to MSISDN' they mean 'store the mobile number in canonical E.164.' Getting that representation right at the point of capture is the difference between a number that routes cleanly and one that silently fails downstream.

Normalization: storing every number in one canonical form

Users type numbers in every imaginable style — with spaces, brackets, a national trunk zero, a 00 or 011 international prefix, or none of the above. Normalization collapses all of those into one canonical E.164 string so that the same physical line is always stored identically. Without it you cannot deduplicate a contact list, match a number against a suppression list, or reliably validate before you spend money sending.

A robust normalizer applies these rules in order:

• Strip all formatting characters: spaces, dashes, dots, and parentheses.
• Convert an international access prefix — a leading 00 (ITU) or 011 (North America) — into a '+'.
• If the number already starts with '+', keep the country code as given.
• If it is in national form (no country code), remove the national trunk prefix — usually a single leading 0 — and prepend the default region's country code.
• Reject anything that is not a '+' followed by 1 to 15 digits, with a first digit of 1–9.
• Store only the '+' and digits; regenerate pretty display forms on the fly when you show the number.

The trunk-zero step is the one that trips teams up. In most countries the leading 0 you dial nationally is a trunk prefix that is dropped in international form — a UAE mobile written 050 000 0000 becomes +971 50 000 0000, not +971 050…. Applying the country code without removing that 0 produces an invalid number that looks plausible. The normalizer must know the default region to resolve national-format input; the same digits mean different lines in different countries.

1function toE164(raw, defaultRegion) {
2  // 1. strip spaces, dashes, dots, parentheses
3  let s = raw.trim().replace(/[\s().\-]/g, '');
4 
5  // 2. international prefix 00 (ITU) or 011 (NANP) -> +
6  s = s.replace(/^(00|011)/, '+');
7 
8  // 3. already in international form? keep the country code
9  if (s.startsWith('+')) return assertE164(s);
10 
11  // 4. national form: drop the trunk 0, prepend the region code
12  s = s.replace(/^0/, '');
13  return assertE164('+' + defaultRegion.dialCode + s);
14}
15 
16// assertE164 accepts only /^\+[1-9]\d{1,14}$/  (plus, then <= 15 digits)

Here is the same logic applied to real GCC and international examples. Note how varied inputs collapse to one clean MSISDN:

For one-off checks the phone number formatter shows a number's national and international display forms alongside its E.164 output; for cleaning an entire upload before a campaign, the number list validator normalizes, deduplicates, and flags invalid rows in the browser so raw data never leaves your machine.

Syntactic validity is not reachability

Normalization and length checks tell you a number is well formed — the right shape, a valid country code, within 15 digits. They cannot tell you the number is assigned to a live subscriber. A syntactically perfect E.164 number can be unallocated, deactivated, or ported to a different operator than its prefix suggests. Sending to it still costs you, and it depresses your delivery rate.

Confirming real reachability requires querying the operator's subscriber database. An HLR lookup returns whether a number is currently assigned and active, its true home network (the MCC/MNC behind any ported number), and its roaming status — the ground truth that syntax alone cannot provide. The sensible pipeline is: normalize to E.164 first, discard the syntactically invalid rows cheaply, then run HLR lookups on the survivors before a large or high-value send.

Why formatting errors cost delivered messages and money

A2P SMS is billed per segment on submission, not on delivery. A malformed number is a message you pay to attempt and that never arrives — and at list scale those failures compound. Bad formatting also masks duplicates (the same line stored three ways is billed three times), corrupts your delivery-rate metrics, and can trip operator filters when a gateway receives numbers it cannot parse.

The cheapest fix sits entirely on your side of the API: normalize at the point of capture, validate the E.164 shape before you enqueue, and reserve HLR lookups for the numbers that pass. Teams building this into their own stack can wire it once against a messaging API — see the developer docs — so every number is canonical before it is ever charged for. National-versus-international handling is not an edge case in MENA either: GCC senders routinely receive UAE, KSA, and Egyptian numbers in local form, and each needs its own trunk-prefix rule to normalize correctly.

Frequently asked questions

What is E.164 format?

E.164 is the ITU-T international numbering standard for phone numbers. A number in E.164 format is a leading '+', a country code of one to three digits, and the national number, written as digits only with no spaces or separators and a maximum of 15 digits — for example +971500000000. It is the canonical form for storing any phone number so it can be routed internationally.

How do I validate an international phone number?

Validate in two stages. First, syntactic: normalize the input to E.164 (strip formatting, convert 00/011 prefixes to '+', remove any national trunk zero, apply the country code) and confirm it is a '+' followed by 1 to 15 digits. Second, reachability: run an HLR lookup to confirm the number is actually assigned and active. Syntactic validity alone does not prove a number can receive messages.

What is MSISDN normalization?

MSISDN normalization is the process of converting a mobile number written in any local or formatted style into its canonical E.164 MSISDN — the dialable international number the network routes to. It strips separators, resolves the trunk prefix and international access prefix, and applies the correct country code, so the same line is always stored identically for deduplication, validation, and reliable delivery.

References

• ITU-T Recommendation E.164 — the international public telecommunication numbering plan: itu.int
• ITU-T Recommendation E.212 — international identification plan for public networks and subscriptions (IMSI, MCC/MNC): itu.int
• BroadNet — phone number formatter and number list validator for E.164 normalization.
• BroadNet — HLR lookup for confirming true reachability beyond syntactic validity.