What E.164 represents
An international E.164 number begins with a plus sign in its written representation, followed by the country calling code and national significant number. The digits identify a destination in the international public telecommunication numbering plan; spaces, parentheses and hyphens are presentation choices, not part of the canonical value.
For example, a US fixture displayed as (202) 555-0123 becomes +12025550123. A UK mobile fixture displayed as 07700 900123 becomes +447700900123 because the domestic trunk zero is removed before adding +44.
Normalize in four steps
- Capture country context. A national number alone is ambiguous. Ask for a country or infer it only from trusted account context.
- Parse with a maintained numbering library. Do not implement every national plan with hand-written string rules.
- Validate for the job you are doing. Structural validity, possible length, line type and reachability are different questions.
- Store the canonical value. Persist the normalized E.164 representation and format it for display when rendering the UI.
Try the browser-based E.164 formatter to compare national, international and RFC 3966 output.
Country calling codes and trunk prefixes
A country calling code is not always the same as the first digits users type domestically. Many national plans use a trunk prefix such as 0 for calls within the country. That trunk prefix is normally omitted from the international E.164 value. The exact rule belongs to the national numbering plan, which is why country context must be known before normalization.
North American Numbering Plan countries share +1, so the country code alone does not distinguish the United States from Canada. Use the full numbering plan and application context instead of treating +1 as a country identifier.
Storage and API design
Use a text column, not an integer. A phone number is an identifier: arithmetic is meaningless, the leading plus sign matters, and the value can exceed assumptions made for local numeric types. A practical record can store phone_e164, the user-selected region, validation timestamp and verification state separately.
Do not use formatting as proof of ownership. If your product must confirm control, run a separate consent-based verification flow and store that result with an expiry or audit timestamp.
Common implementation mistakes
- Removing a leading zero before country context is known.
- Rejecting spaces or punctuation instead of normalizing pasted input.
- Using one regex for every country and every number type.
- Assuming a structurally valid value is assigned or SMS-capable.
- Formatting the stored value differently on each platform.
Standards and references
Use the current ITU-T E.164 recommendation for the international numbering model and IETF RFC 3966 for tel: URIs.
Review checklist before using E.164 in production
Before a release, test at least one national and one international input for every country you support. Confirm that domestic trunk prefixes are handled per country, shared calling codes are not treated as a single country, and formatted display values can round-trip back to the same stored E.164 value. Store the parser metadata version beside critical decisions so a later numbering update can be reviewed deliberately.
E.164 is the storage shape, not the complete phone workflow. Keep extension, consent, verification state, preferred display region and delivery result in separate fields. This avoids a common bug where a formatting change unexpectedly affects login recovery, duplicate detection or notification eligibility.
How this guide connects to the toolkit
This page is written as an implementation reference, not a generic glossary. Use it with the interactive tools when you need to turn an idea into a testable behavior: generate a fixture, format it, validate the structural claim, then record the country and expected result beside your product test. Keeping the explanation and tool output connected helps future reviewers understand why a number was accepted or rejected.
If you copy an example into your own documentation, also copy the safety context. A phone string without its country, source note and limitation can look like a contactable number. The surrounding guidance is part of the value of the fixture.