E.164 Phone Number Format: The Developer's Complete Guide

What E.164 is, exactly

The E.164 phone number format is the ITU-T standard that defines the international public telephone numbering plan. The rules fit in a sentence: a leading +, then the country code, then the national number, with no spaces, dashes, or parentheses, and a maximum of 15 digits total (not counting the +). That is the entire specification a developer needs: +14155550123, +442071838750, +919812345678.

Why it matters so much for SMS: providers route on E.164, and a malformed number is the single largest source of silent OTP failures. Get the format right at intake and a whole category of delivery bugs disappears before it starts. The same point our delivery benchmark guide makes about valid numbers being the baseline every delivery statistic assumes. For authoritative details on numbering plans, see the ITU-T E.164 recommendation itself.

The rules, and the one everyone breaks

Validating and normalizing in code

# Shape gate (cheap, first pass):  ^\+[1-9]\d{1,14}$
#   + then a non-zero country-code digit then up to 14 more digits.
# It rejects: missing +, leading zero after +, >15 digits.
# It does NOT know national trunk zeros or per-country length -> use a library.

• Gate with the regex ^\+[1-9]\d{1,14}$ at intake to reject obvious garbage instantly.
• Normalize with libphonenumber (Google's, ported to most languages). It knows each country's trunk-zero and length rules and outputs canonical E.164.
• Store the E.164 string, not the user's formatting. Normalize once at write time, and every downstream send, lookup, and dedupe just works.
• Capture the country context when you can (from the form, IP, or a country selector), because '0412345678' is ambiguous without knowing it is Australian.

Where E.164 pays off downstream

1. Reliable deliveryProviders route on E.164; a correctly formatted number is the precondition for the OTP send actually reaching a handset. When sending via SMPP, the E.164 number is placed in the destination address field of the submit_sm PDU.
2. Accurate lookupsA number lookup or HLR query needs canonical input to return correct line-type and carrier data — garbage in, null out.
3. Clean deduplicationNormalizing to E.164 means '+44 20...', '020...', and '+4420...' collapse to one record, so you don't message the same person twice or store them thrice.
4. Correct cost estimationThe country code in E.164 is what determines the per-message rate — the routing logic behind our international cost guide.

SMSRoute is a no-KYC SMS API with crypto billing (BTC, ETH, USDT, XMR, LTC, and SOL), and like every serious SMS API it expects E.164 input. Normalize at your intake boundary once, store the canonical form, and the 5-line send never has to think about phone formatting again. It is a small discipline that removes an entire class of silent failures — the same preventable category as the invalid numbers our delivery benchmark guide counts against every route's real rate. For more on SMS concatenation and encoding, see the GSMA SMS specification. SMSRoute's published route pages list delivery from $0.004/message (premium direct-carrier corridors up to $0.035) with sub-100ms median submission and ~98.6% delivered success (smsroute.cc route pages, 2026).

Related reading

FAQ