E.164 Phone Formatter

How the Formatter Normalizes and Validates Numbers

Input is first stripped of formatting characters (spaces, dashes, dots, parentheses) while preserving a single leading +. A leading 00 is treated as the international access prefix and converted to +. If the string starts with +, the tool matches the longest country dial code from a built-in list (15 countries covering the most common CRM regions). If there is no +, the selected country dropdown supplies the dial code; its national trunk prefix (0 for most European countries, omitted for NANP) is then stripped if the remaining length still matches the expected national digit count for that country.

Validation checks three things: the national significant number must match one of the expected lengths for the matched country (e.g. 10 for US/UK/Germany mobile, 10 or 11 for Brazil), the total digit count including country code must not exceed the 15-digit E.164 maximum, and the first digit of the country code must be 1–9 (0 is never valid as a country code). A warning is raised when the national number starts with 0, which usually means a trunk prefix was left in place. The batch audit mode runs the same logic per line and produces a count of valid, invalid (with exact reason), and duplicate E.164 strings.

Trunk prefixes and the + prefix

The leading 0 in a UK number like 020 7946 0958 is a domestic trunk prefix, not part of the subscriber number. When dialing internationally you replace it with the country code: +44 20 7946 0958. Storing +4402079460958 (with the 0 kept) creates a number that no network can route. The tool’s trunk-prefix stripping removes the 0 only when the national length still matches after removal, so a legitimate leading 0 in a country that uses one is not stripped incorrectly.

Why length tables matter

E.164 caps the total at 15 digits, but individual countries use shorter national numbers. US and Canadian numbers are always 10 national digits; German landlines are 10–11; Brazilian mobile numbers are 11 (with the 9th digit). The tool encodes these rules per country so a truncated paste or an extra digit is caught immediately rather than failing silently at the API stage with a cryptic “invalid To number” error.

Before and after: normalizing a CRM import column

Before (raw CSV column, mixed formats)

415-555-2671
020 7946 0958
+49 30 901820
(0)11 282 8600
+14155552671
not-a-phone
+4402079460958

After (batch audit output)

Valid: 4  Invalid: 2  Duplicates: 1

+14155552671   ← 415-555-2671 (US, +1)
+442079460958  ← 020 7946 0958 (UK, trunk 0 stripped)
+4930901820    ← +49 30 901820 (DE)
+27112828600   ← (0)11 282 8600 (ZA, trunk 0 stripped)
✗ not-a-phone  → empty national number after + prefix
✗ +4402079460958 → trunk 0 left in national part
⚠ +14155552671 duplicate of line 1

Use Cases

Developer	Production	Workflow
Normalize phone input before calling Twilio or WhatsApp Business API	Validate numbers at form submit with the E.164 regex	Audit a 5,000-row CRM export before import
Strip trunk prefixes in a multi-country lead-routing service	Deduplicate contacts whose numbers differ only by formatting	Standardize phone fields across Salesforce, HubSpot, and a legacy CSV
Debug an SMS delivery failure caused by a leftover 0 prefix	Store the canonical E.164 in the database, format for display in the UI	Train a data-entry team on the expected input format

Common Mistakes

Storing the national trunk prefix in the E.164 string. +4402079460958 has an extra 0 after the country code; the correct form is +442079460958. Most CPaaS APIs reject the former with an “invalid number” error.
Omitting the country code entirely. 4155552671 is ambiguous — it could be a US number or part of a longer international sequence. Always store the leading + and country code.
Using the E.164 regex as the sole validator. /^\\+[1-9]\\d14$/ accepts structurally valid but non-assigned numbers; pair it with a real numbering-plan library for production systems.
Cramming an extension into the E.164 string. Extensions are not part of E.164; store them in a separate field and append in dial strings or IVR menus.
Pasting a full international format like +44 20 7946 0958 and expecting the tool to know the country without the + or a dropdown selection. Without +, you must select the origin country so the trunk prefix can be stripped correctly.
Importing a CRM list without deduplicating. The same contact may appear as 415-555-2671, (415) 555-2671, and +14155552671; only the batch audit mode catches these as duplicates after normalization.

Best Practices

Store the canonical E.164 string in the database. Format for national display in the UI using the country metadata, but keep the storage format machine-parseable.
Validate at input time with the E.164 regex plus a country length check, and surface a clear error message (“Enter a 10-digit US number with country code”) rather than a generic “invalid phone.”
Run the batch audit before every CRM import. It catches formatting variants, missing country codes, and duplicates in one pass, saving hours of manual cleanup later.
Separate extensions into their own field. E.164 does not include extensions; appending them to the stored number breaks API validation and carrier routing.
For global products, pair the regex with libphonenumber (or a maintained equivalent) in your backend. This tool’s length tables cover the most common countries; libphonenumber covers every numbering plan with carrier-specific rules.
Log the raw input alongside the normalized E.164 in analytics. This lets you trace a delivery failure back to the exact string the user typed, which is often the fastest way to spot a trunk-prefix bug in a specific country’s flow.

Frequently Asked Questions

What is E.164 format and why do APIs require it?

E.164 is the ITU-T standard for phone number formatting: a leading + followed by country code, national destination code, and subscriber number, with a maximum of 15 digits total. APIs from Twilio, Vonage, WhatsApp Business, and most CPaaS providers accept only E.164 because it removes ambiguity — there is no trunk prefix, no extension, no formatting characters. A number stored as (415) 555-2671 is US-specific; +14155552671 is globally unique and machine-parseable.

How do I convert a local number like 020 7946 0958 to E.164?

You need the country calling code for the number’s origin. For the UK, the country code is 44 and the national trunk prefix is 0, so you strip the leading 0 and prepend +44, giving +442079460958. This tool does that automatically when you select the country from the dropdown — it removes the trunk prefix (if the national length still matches after stripping) and validates the result against the expected digit count for that country.

Why is my +44 number being rejected as invalid?

The most common cause is a trunk prefix left in the national part: +4402079460958 has an extra 0 after the country code and will fail validation. Another cause is a number that is too short or too long for the UK’s 10-digit national format. The tool shows a warning when the national number starts with 0 (likely a leftover trunk prefix) and an error when the total digit count exceeds the 15-digit E.164 maximum.

Can I store extensions in E.164?

No. E.164 deliberately excludes extensions; the standard is for the primary line only. If your CRM needs an extension, store it in a separate field (often called “ext” or “subscriberNumber”) and append it in dial strings or IVR menus after the E.164 base number. Tools that try to cram extensions into the E.164 string break downstream API validation.

How does the batch audit mode work for CRM imports?

Paste one phone number per line. The tool runs the E.164 normalization on each line, counts valid and invalid entries, lists the exact reason for each failure (unknown country code, wrong length, empty national number), and detects exact duplicates of the normalized E.164 string. This catches the classic import bugs: numbers with hyphens that got split across CSV columns, missing country codes on international rows, and double-entered contacts.

Is the E.164 regex /^\+[1-9]\d{1,14}$/ sufficient for validation?

That regex is the structural rule from ITU-T E.164: a leading +, a non-zero first digit (so 0 is never a country code), and up to 15 total digits. It is necessary but not sufficient — it accepts structurally valid but non-assigned numbers like +999123456 if 999 were a valid country prefix. For production systems, pair the regex with a library like libphonenumber that checks against real numbering plans; use this regex as a fast pre-filter.

Does this formatter send my phone data anywhere?

No. All parsing, trunk-prefix stripping, and length validation run in the browser. The numbers you paste, including bulk CRM lists, never leave the tab; nothing is stored in localStorage or sent to a server. You can disconnect from the network and the tool keeps working.