What E.164 is, and why your list probably isn't in it

Almost every rejected message, failed API call and mysteriously undeliverable contact traces back to the same thing: the number was not in E.164, and the system on the other end refused to guess what you meant.

E.164 is the ITU standard that gives every phone number on earth exactly one canonical written form. It is a short rule, and once your list follows it, an entire category of problems disappears.

The rule

An E.164 number is a plus sign, then digits, and nothing else, no spaces, no brackets, no dashes, no leading zero. Maximum fifteen digits after the plus.

+14155552671      US, 11 digits
+442071838750     UK, 12 digits
+2348031234567    Nigeria, 13 digits
+61291234567      Australia, 11 digits

Those digits break into three parts:

• Country code, one to three digits (1 for the NANP, 44 for the UK, 234 for Nigeria).
• National destination code, the area or mobile-network code. In the US this is the three-digit area code; in the UK it is the 20 in an 020 London number.
• Subscriber number, the rest.

The four things that break it

1. The trunk prefix that should have been dropped

This is the big one, and it is the mistake that survives longest because the number still looks right. Most countries put a digit in front of a number when you dial it domestically, a trunk prefix, usually 0. A London number is written 020 7183 8750 at home. The 0 is dialling instruction, not part of the number. Internationally it is dropped:

020 7183 8750   ->  +44 20 7183 8750   correct
020 7183 8750   ->  +44 020 7183 8750  wrong -- extra 0

The same applies to Nigeria (0803… becomes +234803…), Australia, India, Germany, most of Europe and most of Africa. It does not apply to the NANP, which has no trunk prefix. 1 there is the country code itself, not a trunk digit, which is exactly why the two get confused.

2. The double prefix

00, 011 and 810 are international access codes — what you dial to get out of your own country. They are not part of the number and they are not interchangeable with +. 0044… in a field that expects E.164 is malformed. So is +0044…, which manages both mistakes at once.

3. Country assumed instead of stored

A column of 5551234 and 7183 8750 is not a phone list, it is a list of fragments. Nothing in those digits says which country they belong to, and no tool can tell you, including this one. A seven-digit string is a valid subscriber number in dozens of numbering plans simultaneously.

If your source system stored the country separately (a billing address, a signup locale, a store region), you need that column joined back on before conversion. If it did not, the honest answer is that those rows cannot be recovered from the digits alone. Segment them and treat them as a data-collection problem, not a formatting one.

4. Formatting characters that survived the export

(415) 555-2671, 415.555.2671, +44 (0) 20 7183 8750. The last one is the nastiest: it is a common British house style that embeds the trunk zero in brackets as a courtesy to domestic callers. Strip the punctuation naively and you get +442007183875. The zero has silently become part of the number.

Where the country code has to come from

Every conversion to E.164 turns on one question: which country is this number in. If you know that, the rest is mechanical. If you do not, no amount of string manipulation will tell you, and guessing is how lists get quietly corrupted.

Three sources, in descending order of trust:

1. A country field already on the row. Best case, and the reason to capture it at the point of collection even when it feels redundant.
2. The number already carrying its own prefix, either as a leading + or as an international access code such as 00 or 011. This is self-describing and needs no assumption.
3. A stated default for the file. Acceptable only when you genuinely know the list is single-country, and it should be a decision you record rather than a setting you forget.

What does not work is inferring country from the number's shape. A ten-digit number could be US, Canadian or a dozen other plans. A nine-digit number with a leading 7 could be Russian, or it could be a UK mobile with the trunk zero already stripped. These collide constantly, and a tool that silently picks one is producing numbers that look perfect and dial nowhere.

The safe behaviour when country cannot be established is to leave the row alone and mark it for review. A number you could not convert is a visible problem. A number you converted wrongly is an invisible one, and it stays in your database for years.

Converting a list, in order

1. Strip everything that is not a digit or a leading plus. Spaces, brackets, dashes, dots, and the non-breaking spaces that come out of spreadsheet exports.
2. Normalise the international access code. A leading 00 or 011 becomes +.
3. Establish the country for every row. From the country code if the number already carries one, otherwise from a separate column. Rows where you have neither get set aside, do not guess.
4. Drop the trunk prefix for that country, if the remaining national number starts with it. This is per-country, which is why a find-and-replace does not work.
5. Check the result against the country's numbering plan — correct length, and an actual allocated block rather than a plausible-looking one.

Steps one and two are a regular expression. Steps three to five are why phone formatting libraries exist: the rules are per-country, they change, and there are roughly two hundred of them.

The spreadsheet problem

More correctly formatted E.164 lists are destroyed by a spreadsheet than by any other single cause, and it happens after the work is done.

Open a clean CSV in Excel and the phone column is interpreted as a number. The leading plus is a mathematical sign, so it is discarded. A fifteen-digit value exceeds the precision Excel keeps for a number, so it may come back as 1.41556E+10 or with trailing digits replaced by zeros. Save the file and the damage is now on disk. Nothing warns you, because from the spreadsheet's point of view nothing went wrong.

Three ways round it, in order of reliability:

• Do not open the file in a spreadsheet at all. If a tool can read the CSV directly, let it.
• Set the column type to Text before the data loads, using the import dialog rather than opening the file by double-clicking it.
• Prefix each value with an apostrophe in Google Sheets, which forces text and is not itself exported.

The same hazard applies to any column of long digit strings, which is why account numbers and order references suffer from it too. Phone numbers are simply the case where the corruption is most expensive, because a number with a dropped plus and a mangled tail is still the right length to look plausible.

Non-obvious characters that break the format

Punctuation is easy to strip. The characters that survive a naive clean are the ones that do not look like characters:

• Non-breaking spaces, which arrive through copy and paste from web pages and documents and are visually identical to a normal space.
• Zero-width and directional marks, common in numbers copied from right-to-left contexts, which occupy no width at all.
• Full-width digits, which read as ordinary digits but are different characters entirely.
• Trailing extensions written as "x210" or "ext 210", which belong in their own field and are not part of the number.

A conversion routine that only knows about spaces, dashes, brackets and dots will pass these through unchanged and then report the row as invalid. The row is not invalid; the clean was incomplete. Worth checking, because a validator that reports a suspiciously high failure rate on one particular source file is usually telling you about the export, not about the numbers.

Well-formed is not the same as real

This is the distinction most cleaning scripts miss, and it is worth being precise about.

+1 999 999 9999 is perfect E.164. Right length, valid structure, passes every regex you can write. It is also not a phone number, the NANP never allocated the 999 area code, so nothing is on the other end.

Checking the shape of a number tells you it could exist. Checking it against the numbering plan tells you whether the block it sits in was ever handed to a carrier. Those are different questions, and only the second one saves you money on a send.

Store it in E.164, always

Convert on the way in, not on the way out. Store the canonical +-prefixed string in your database and format it for display at the point of display. Every system that has ever had a phone-number data-quality problem got there by storing whatever the user typed and hoping to sort it out later.

Common questions

How do I convert a phone number to E.164 format?

Establish the country first, then strip all punctuation and whitespace, convert a leading international access code such as 00 or 011 to a plus, remove the national trunk prefix if that country uses one, and prepend the country code. The order matters: stripping punctuation before handling the trunk prefix is what turns +44 (0) 20 into a number with an extra zero in it.

What is the format of a US-based phone number?

Ten digits: a three-digit area code, a three-digit central office code, and a four-digit line number. In E.164 it carries the +1 country code, giving a plus, then 1, then those ten digits, with no spaces, brackets or dashes.

Is it +1 for all US and Canadian numbers?

Yes. The United States, Canada and around twenty Caribbean territories all share +1 under the North American Numbering Plan. This is also why a +1 number alone does not tell you which country it is in, and why country-level reporting from a phone list is less reliable across +1 than elsewhere.

What does the 164 in E.164 mean?

It is the number of the ITU-T recommendation that defines the international public telecommunication numbering plan. The 164 is a document number rather than anything about the numbers themselves. The rule it sets is the useful part: a country code followed by a national number, fifteen digits maximum in total.

Does a valid E.164 number mean the number works?

No, and this is the distinction that matters most. E.164 is a syntax rule. A number can satisfy it completely and still sit in a block that no carrier was ever allocated, in which case it cannot ring. Format validation and existence checking are separate steps, and passing the first says nothing about the second.