Skip to main content
Back to blog

National format vs E.164: how phone number formatting works

E.164 is the canonical international form of a phone number; national format is the local dialing form users actually type. This explainer covers both, when to use each, and the normalization mistakes that break SMS and voice routing.

Orbit Editorial Team

A phone number has two written forms that matter in practice: E.164, the international canonical form such as +442079460018, and national format, the local dialing form a person in that country would type, such as 020 7946 0018 in the UK or (415) 555-0142 in the US. Systems should store and route in E.164 and display in national format; most number-formatting bugs in messaging and voice come from doing it the other way around.

What E.164 gives you

E.164 is the ITU-T recommendation that defines the international public telecommunication numbering plan. In practice it means: a plus sign, a country code, and a subscriber number, with no spaces, dashes, or leading trunk prefix, up to fifteen digits. It is unambiguous. Given +442079460018, every carrier, API, and database on the path knows the country and the destination without guessing. That is why SMS APIs, voice APIs, and verification flows all ask for E.164: it is the only form that survives crossing borders and systems without interpretation.

What national format gives you

National format (also called national significant number formatting, or local format) is how the same number is written and dialed inside its own country: with the national trunk prefix (the leading 0 in much of Europe, the 1 plus area code convention in North America) and with the spacing or grouping locals expect. It is the form a customer recognizes as "their" number on a statement, a website, or a caller ID line. National format carries no country information, which is exactly why it is dangerous as a storage format: 020 7946 0018 means nothing to a system that does not already know the number is British, and (555) 0142-style strings collide across countries.

The pair in one table

Take three examples. The US number +14155550142 in E.164 is written nationally as (415) 555-0142. The UK number +442079460018 reads nationally as 020 7946 0018, note the leading zero that E.164 drops. Germany's +49301234567 becomes 030 1234567. The pattern to remember: E.164 removes the national trunk prefix and adds the country code; national format restores the trunk prefix and removes the country code. Converting one way requires knowing the country; converting the other way requires removing ambiguity.

Where each form belongs

Store and route in E.164. APIs for SMS, voice, verification, and number inventory all key on it. Deduplication, consent records, and opt-out lists must use it too, because a customer who opted out as +442079460018 and reappears as 020 7946 0018 is the same person, and only normalization catches that.

Display in national format. Caller ID lines, invoices, support screens, and printed material read better in the form the reader dials. A London customer scanning a statement recognizes 020 7946 0018 at a glance and has to work to recognize the E.164 form.

Collect with country context. A web form that asks for a phone number should pair the input with a country selector and normalize to E.164 on submit. Free-text national numbers with no country hint are the single largest source of undeliverable messages in any migration we see.

The normalization mistakes that cause real incidents

Dropping or keeping the trunk prefix incorrectly is the classic one: dialing 020 7946 0018 as +44 020 7946 0018 (keeping the zero) fails or misroutes in many networks, and storing +442079460018 as 2079460018 (dropping too much) loses the trunk semantics entirely. Second, assuming domestic numbers: a CRM full of 10-digit US numbers is fine until a Canadian or Jamaican number arrives wearing the same shape. Third, treating formatted strings as identifiers: spaces, parentheses, and dashes are presentation, and two strings that differ only in formatting must normalize to one E.164 key. Fourth, ignoring that some countries change numbering plans; area codes split, and previously valid national forms stop resolving. Number inventory and regulatory previews, the kinds of tooling Orbit ships for provisioned ranges, exist partly to keep display forms aligned with current plans.

How Orbit handles the pair

Orbit stores every number in E.164 across messaging, voice, and verification surfaces, and applies per-country national formatting when numbers are displayed in the console, in exports, and on caller-facing surfaces. Hosted messaging and international freephone guides in the Orbit docs touch on national format where local dialing behavior matters, and the numbering guidance follows the same rule: canonical E.164 internally, national presentation externally. When you import a customer list, the platform normalizes to E.164 and flags records that cannot be normalized with a single unambiguous interpretation, so a malformed row becomes a queue item instead of a silently misrouted message.

Practical checklist

Validate on input with a country hint and store the E.164 result. Keep the original string if you need an audit trail, but never route on it. Render national format per locale at display time only. Match consent, opt-out, and dedupe on the E.164 key. And when a carrier or regulator document refers to "national (local) format," read it as the display-side twin of E.164, the same number, written for the person who dials it.

National format vs E.164: how phone number formatting works — Orbit by Devotel