Phone number formats explained: E.164, trunk zeros and country quirks
Phone numbers look simple until you route SMS or validate sign-ups at scale. E.164 is the interchange format APIs expect, but national dialing habits—trunk zeros, local prefixes, copied chat formats—break pipelines daily. This guide covers E.164 anatomy, trunk and international prefixes, common breakage patterns, and a practical batch-cleaning workflow. Spec-level facts only; country details live in numbering plans and our country fact sheets.
E.164 anatomy: the interchange format
E.164 is the ITU-T recommendation that defines the international public telecommunication numbering plan. In practical terms it is how almost every SMS API, voice carrier interconnect, and global identity system wants a number represented: a plus sign, a country code, then the national significant number, with no spaces, dashes, or parentheses. The plus is not decoration; it marks the string as an international full number rather than a domestic dialing sequence.
The structure is fixed at the specification level. A complete E.164 number starts with +, followed by a country code of one to three digits, followed by the national significant number. The entire digit string after the plus must not exceed fifteen digits. That fifteen-digit maximum is a hard ITU limit, not a product preference. Country codes are ITU-assigned; they are not free-form fields you invent per market.
What E.164 deliberately does not encode is how a person dials from inside a country. National trunk prefixes, carrier selection codes, and local area-code punctuation are out of scope. When you see a string such as +14155552671 you are looking at country code 1 plus a national number; you are not looking at how someone would type that number into a domestic landline keypad.
For developers the durable rule is: store and transmit in E.164, and apply locale-aware display formatting only in the presentation layer. Mixing interchange form with national dialing form is the root of most validation and routing bugs. Our normalizer tool and country fact sheets stay aligned to this split—canonical E.164 out, plan-level notes for the quirks.
SMSRoute's MCC-MNC lookup shows which network an allocation belongs to once a number is clean.
| Component | Spec-level rule |
|---|---|
| Plus sign | Literal + marking international format |
| Country code | 1 to 3 digits, ITU-assigned |
| National significant number | Remainder after country code |
| Total length | At most 15 digits after the + |
| Separators | None in the canonical form |
Trunk prefixes: the leading zero that must disappear
Many national numbering plans use a trunk prefix—most often a leading 0—when someone dials a full national number from inside that country. The trunk prefix is a domestic dialing instruction. It is not part of the national significant number that E.164 carries after the country code.
The common international convention is to drop the trunk prefix when forming an E.164 number. A user who writes a national number that begins with 0 is usually giving you the domestic dial string. In the international form the 0 after the country code should not appear. Keeping it yields a digit sequence that does not match the subscriber on the public network and will fail routing or reach the wrong destination.
This convention is widely adopted, but it is not a single global statute written once for every plan. National numbering plans define whether a trunk prefix exists, what digit or digits it uses, and how fixed and mobile ranges behave. Some plans have no trunk zero. Some apply different prefixes for different call types. Do not hard-code a universal “strip one leading zero after country code” rule and call it finished. Point to the relevant national numbering plan or to our country fact sheets for the plan-level behavior.
Be honest about uncertainty. If your row is only a national-format string plus a guessed country, you cannot always know whether a leading zero is a trunk prefix or a meaningful digit. Country context is mandatory for correct normalization. When context is missing, quarantine the row rather than guessing.
International dial prefixes: 00, 011, and +
Before softphones and mobile address books made + ubiquitous, callers reached the international gateway with an international call prefix. That prefix is not part of the remote party’s number. It tells the local exchange to open an international call. Raw user data and CRM exports still contain these prefixes constantly.
Two prefixes dominate messy inputs. Many countries use 00 as the international prefix. The North American Numbering Plan region commonly uses 011. When a user pastes a string that begins with 00 or 011 followed by a country code and national number, they have included their origin’s international dial prefix. The E.164 form removes that prefix and uses + instead. The plus sign is the standardized, origin-independent substitute for whatever international prefix the caller would have dialed.
APIs standardize on + because 00 and 011 are origin-dependent. A number that looks correct for a caller in one country is wrong if you literally store the prefix as part of the destination. Related failure modes include stacking: a field that already contains a country code receives another international prefix or a second country code during copy-paste, form autofill, or import mapping. Heuristics can look for known international prefixes at the start and for repeated country-code patterns, but they still need intended-destination country as context to decide safely.
SMSRoute's free E.164 normalizer applies these rules to whole lists client-side.
Why SMS APIs demand E.164—and how numbers break
SMS and voice APIs demand E.164 because routing is international by default. The gateway must know the destination country without guessing from billing address, browser locale, or the sender’s home market. E.164 removes national dialing ambiguity: one canonical digit string maps to one destination on the public network. Optional formatting in the UI is fine; optional formatting on the wire is not.
When upstream data is messy, a handful of breakage patterns dominate. Double country codes appear when a national number is converted twice, or when a UI prepends a country code to a value that already contained one. Kept trunk zeros leave a domestic trunk digit after the country code, so the string no longer matches the national significant number. Formatting characters—spaces, dashes, parentheses, dots—survive copy-paste from contacts apps and spreadsheets and must be stripped before length and prefix checks. Chat-app and WhatsApp-copied formats often mix a leading + with spaces or embed the number in a URL or vCard-like fragment; naive parsers keep non-digit noise or split the string incorrectly.
None of these failures is exotic. They show up in CSV imports, CRM syncs, support tooling, and mobile signup forms. The remedy is not an ever-longer regular expression. The remedy is a deterministic pipeline that strips presentation characters, interprets international dial prefixes, applies country context to trunk rules, validates E.164 constraints, and either emits a canonical string or rejects with a clear reason. Silent mis-normalization is worse than a rejected row.
Batch-cleaning workflow and tooling
A practical batch-cleaning workflow uses ordered stages. First, normalize the character set and strip everything that is not a digit or a single leading plus. Second, detect and remove international dial prefixes such as 00 or 011 when they appear at the start of the digit string. Third, apply country context: if a default country or per-row country is known, use that plan’s trunk-prefix rules from the official numbering plan or from our country fact sheets to drop a trunk prefix when appropriate. Fourth, validate against E.164 constraints—plus present in the canonical output, country code one to three digits, total digits after the plus at most fifteen. Fifth, emit the canonical E.164 string and retain an audit field for the original raw value plus short transformation notes.
Rows that remain ambiguous—missing country, implausible length after cleanup, or conflicting prefix signals—should not be force-converted. Quarantine them for manual review or a second pass with better country metadata. Downstream SMS and voice calls will not forgive a confident wrong number.
Our normalizer tool implements this pipeline for bulk files and single checks. Use it together with the country fact sheets when you need to explain a trunk or prefix transformation to support, compliance, or a customer. The sheets stick to published plan facts and spec-level limits; they do not invent national significant number lengths beyond what official plans and the E.164 fifteen-digit maximum state.
For online systems, validate at ingress. Accept flexible user input, normalize immediately to E.164, and persist the canonical form. Keep the raw original only if you need an audit trail. Display formatting belongs in the presentation layer, driven by locale-aware libraries, not by whatever string you happened to store. That separation keeps APIs, message routing, and analytics on one unambiguous key.
The SMSRoute country fact sheets list each covered market's calling code with sources.
Frequently asked
- What is E.164 format for a phone number?
- E.164 is the ITU-T international numbering format: a leading +, a country code of one to three digits, then the national significant number, with no spaces or punctuation. The digit string after the plus is at most fifteen digits. It is the canonical form SMS and voice APIs expect for routing.
- Why is the leading zero removed from international phone numbers?
- In many national plans the leading 0 is a trunk prefix—a domestic dialing instruction, not part of the national significant number. The common international convention drops that trunk prefix when building E.164. Whether a plan uses a trunk zero, and when, is defined by the national numbering plan; check plan docs or country fact sheets rather than assuming every country is the same.
- Why do SMS APIs require E.164?
- Because routing is international by default. E.164 tells the gateway the destination country and subscriber without guessing from locale or billing address. National dial strings, trunk zeros, origin dial prefixes like 00 or 011, and punctuation are ambiguous on the wire; canonical E.164 removes that ambiguity.