E.164 phone numbers: default regions, national formats, and what “valid” means

Published: 2026-09-05

How ITU-T E.164, country calling codes, and national formatting relate—and why libphonenumber “valid” only means the number matches region rules, not that the line is live.

E.164 is the ITU-T recommendation for writing a phone number as a single international string: a leading +, a country calling code, then the national significant number (no trunk prefixes, no spaces). APIs, SMS gateways, and CRM fields prefer E.164 because one canonical form avoids “is this UK or US?” ambiguity.

This guide covers the formats you will see in forms and logs, when a default region is required, and what “valid” from Google libphonenumber (and tools built on it) actually proves. Prefer public or synthetic samples—practice offline with the E.164 phone formatter.

Anatomy of an E.164 number

Part	Role	Example (`+14155552671`)
`+`	International prefix marker	Always present in E.164 text
Country calling code	ITU assigned (1–3 digits)	`1` (NANP / US)
National number	Subscriber digits for that region	`4155552671`

Rules of thumb:

No leading zeros after the calling code (UK national 020… becomes +44 20…, not +44020…).
Digits only in the canonical string (formatting punctuation is for display).
Total length is bounded by E.164 (up to 15 digits after + in the recommendation).

Related spellings of the same subscriber:

Format	Example	Typical use
E.164	`+14155552671`	Storage, APIs, SMS
International	`+1 415 555 2671`	Human-readable with `+`
National	`(415) 555-2671`	Local UI when region is known
RFC3966	`tel:+14155552671`	`tel:` links in HTML / vCards

The formatter returns all four when the input parses as a possible number.

Why national numbers need a default region

A string like 020 7946 0958 or 4155552671 has no country calling code. Parsers cannot know whether those digits are UK, US, or something else unless you supply a default region (ISO 3166-1 alpha-2: GB, US, FR, …).

Input	Default region	Typical E.164
`+44 20 7946 0958`	(none needed)	`+442079460958`
`020 7946 0958`	`GB`	`+442079460958`
`020 7946 0958`	none / wrong	Parse fails or wrong country
`4155552671`	`US`	`+14155552671`
`4155552671`	none	Not parseable as international

Best practice for data pipelines: normalize to E.164 as early as you can, then stop relying on default regions downstream. Keep the default region only for UI fields that accept local typing.

On LocalTools, pick None — require +country code when pasting already-international lists, or set a region when cleaning national CSV columns.

Possible vs valid (libphonenumber)

Libraries based on Google’s libphonenumber metadata expose two related checks:

Check	Means	Does not mean
Possible	Length and rough pattern fit the region’s numbering plan	The number is assigned or reachable
Valid	Stricter match against known ranges / patterns for that country	You may call, SMS, or market to it
Number type (mobile, fixed line, toll-free, …)	Best-effort classification from metadata	Current line type at the carrier
Parse error (too short / too long / not a number)	Input failed structural parse	Which business rule to apply

So a UI label like “Valid number” is a format and numbering-plan signal—same spirit as IBAN checksums or Luhn for cards: strong typo filters, not live-line proof.

You will sometimes see possible but not valid: length looks plausible for the region, but metadata does not mark that exact pattern as a known valid subscriber number. Treat that as “do not trust for production routing” until a carrier or HLR-style check says otherwise (those checks are out of scope for a local formatter).

Common pitfalls

Trunk prefixes: National dialing often uses a leading 0 (UK, many EU countries). Strip it when building E.164; keep it only in national display.
NANP +1: US, Canada, and several Caribbean territories share calling code 1. Region detection uses the area code—do not assume every +1 number is US.
Spaces and punctuation: (415) 555-2671 and 415-555-2671 can parse the same; store E.164, display national/international.
Extension / pause characters: ;ext= and similar belong in rich dial strings, not in bare E.164 storage fields.
Regex-only validation: A pattern like “10 digits” ignores country plans and will reject valid international numbers. Prefer metadata-backed parsing.

Safe practice tips

Prefer documented samples (libphonenumber test numbers, carrier sandbox docs) over live customer phones.
Green “valid” is hygiene for forms and imports, not consent or deliverability.
Keep experiments local when lists might be sensitive—see why local-only matters.
Bulk one-per-line lists (# comments OK) help QA fixture files without uploading spreadsheets.

Try it locally

On the E.164 phone formatter:

Paste +1 (415) 555-2671 or +44 20 7946 0958 → copy E.164, international, national, and tel: (RFC3966).
Set default region GB and try 020 7946 0958 → same E.164 without typing +44.
Use bulk list mode for one number per line, then copy TSV for spreadsheets.
Read status carefully: valid vs possible-only vs parse error.

Parsing uses embedded libphonenumber metadata in your browser—nothing is uploaded.