Is E.164 the same as international format?

No. They look almost identical but differ in two ways. E.164 is digits-only after the `+` (no spaces, dashes, or parentheses) and is capped at 15 digits — it is the machine format every API requires. The "international format" most people mean is the **E.123 international notation**: the same digits but written with spaces or punctuation for human readability. `+15551234567` is E.164. `+1 555 123 4567` is E.123 international notation. Same number, different representation.

What is the difference between E.164 and E.123?

They are companion ITU-T standards solving different problems. E.164 defines _which numbers exist_ — the country code allocations, the 15-digit limit, the structure CC + NDC + SN. E.123 defines _how numbers are written_ — recommending the `+` prefix and the use of spaces (not dashes) as separators in human-readable forms. When developers say "international format" in casual usage, they usually mean E.123 notation. When APIs say "international format," they usually mean E.164.

Why do APIs say "international format" when they want E.164?

Sloppy documentation. Twilio, WhatsApp, Stripe, and most identity APIs require strict E.164 (digits-only after the `+`), but their docs sometimes call it "international format" because the term is more familiar to non-technical users. If you see "international format" in an API spec, check the example: `+15551234567` means E.164, while `+1 555 123 4567` means human-readable E.123 notation. When in doubt, send E.164 — it is accepted everywhere E.123 is accepted, and required everywhere E.123 is not.

Can I send `+1 555 123 4567` to Twilio?

Twilio strips spaces internally for many endpoints, so `+1 555 123 4567` often works. But the documented requirement is E.164 (`+15551234567`), and edge cases — webhook payloads, regulatory records, deduplication keys — assume the strict form. Always normalise to strict E.164 before storing or sending. The free converter at the top of this page does the normalisation for any country.

Is `+1-555-123-4567` valid E.164?

No. E.164 allows digits only after the `+` — no dashes, no spaces, no parentheses. `+1-555-123-4567` is informal punctuation. The strict E.164 form is `+15551234567`. Many APIs accept the dashed form because they normalise it for you, but you should not store or transmit it as canonical.

When should I use E.164 vs the international format?

Use E.164 (digits only) for storage, API calls, deduplication, telephony routing, and any system-to-system transmission. Use the human-readable international format (E.123 notation, spaces) for display in emails, contact cards, business cards, and printed material. Most CRMs store one canonical E.164 string per number and render it in the human-readable form on screen.

← Back to blog

Phone Number FormatsMay 3, 20267 min read

E.164 vs International Format: What is the Difference? (2026 Guide)

E.164 Format Converter

Convert any phone number to E.164, international, national or tel: format

Default country (used when the number has no “+”): change it in the country selector at the top of the page.

Privacy: conversion runs entirely in your browser using libphonenumber-js. Numbers never leave your device. Feedback?

You ask a developer for a phone number "in international format" and they send you +1 555 123 4567. You paste it into Twilio and Twilio rejects it. The fix is to remove the spaces — but why? The number is correct. The country code is correct. What changed?

The answer is that E.164 and "international format" are not the same thing, and the difference matters every time you integrate with a phone-number API. This guide explains the distinction in detail, when each form is required, and how to convert between them. The converter at the top of this page handles the conversion automatically — for the technical background, see What is E.164?, and for the worked conversion procedure see How to Convert a Phone Number to E.164.

The Short Version

| Format | Example | What it is | | ------------------------- | ----------------- | ------------------------------------- | | E.164 | +15551234567 | ITU machine format. Digits only. | | International (E.123) | +1 555 123 4567 | Human-readable. Same digits + spaces. |

They are the same number. They are not the same string. APIs almost universally want the first one.

What Each Standard Defines

The ITU-T (the standardisation arm of the International Telecommunication Union) publishes two related recommendations:

E.164 — The international public telecommunication numbering plan. Defines which numbers exist: country calling code allocations, the 15-digit maximum, the three-part structure (country code + national destination code + subscriber number). E.164 is about what is a valid number, not how it is written.
E.123 — Notation for national and international telephone numbers, e-mail addresses and Web addresses. Defines how numbers are written for human reading: the + prefix, the use of spaces (preferred) or hyphens (acceptable) as separators, the optional parentheses around an NDC.

In other words, E.164 specifies the digits and E.123 specifies the punctuation.

When most people say "international format" they mean E.123 international notation — the human-readable form with spaces. When most APIs say "international format" they mean strict E.164 — digits only. Same words, different intent.

Side-by-Side Examples

| Country | E.164 | International (E.123) | | -------------- | ---------------- | --------------------- | | United States | +15551234567 | +1 555 123 4567 | | United Kingdom | +447911123456 | +44 7911 123456 | | Germany | +493012345678 | +49 30 12345678 | | France | +33123456789 | +33 1 23 45 67 89 | | Brazil | +5511912345678 | +55 11 91234-5678 | | Japan | +81312345678 | +81 3 1234 5678 | | India | +919876543210 | +91 98765 43210 | | China | +8613812345678 | +86 138 1234 5678 | | UAE | +971501234567 | +971 50 123 4567 | | Australia | +61412345678 | +61 412 345 678 |

The digits are identical down the column. Only the spacing changes.

When E.164 Is Required (and "International" Will Fail)

These systems all require strict E.164 even though their docs sometimes call it "international format":

| System | Why | | --------------------------------------------------- | ----------------------------------------------- | | Twilio (SMS, Voice, Verify) | Telephony routing requires unambiguous strings. | | WhatsApp Business API | Strict format reduces routing errors at scale. | | WhatsApp wa.me URLs | URL specification — digits only after the /. | | Stripe Identity / Phone | Identity verification dedupe key. | | AWS End User Messaging (Pinpoint) | SMS originator routing. | | GSMA SS7 / SIP signalling | E.164 is the protocol address format. | | Most CRMs (HubSpot, Salesforce custom phone fields) | Recommended for cross-country dedupe. |

If you send an E.123-style number with spaces to most of these and they accept it, they are normalising for you. The contract is still E.164 — and the moment you cross a webhook boundary or a downstream integration that does not normalise, you get an "invalid number" error.

When the Human-Readable International Form Is Right

| Use case | Best format | | ------------------------------ | --------------------------- | | Business card | International (with spaces) | | Email signature | International (with spaces) | | Marketing collateral, web copy | International (with spaces) | | Contact card UI display | International (with spaces) | | Printed customer documentation | International (with spaces) | | Database storage | E.164 | | API request bodies | E.164 | | Webhook payloads | E.164 | | Logs / analytics dedupe keys | E.164 |

The pattern most CRMs follow: store one canonical E.164 string, render in international notation on display. The display is a presentation concern; the storage is a data-integrity concern.

The Three Mistakes That Cause "Invalid Number" Errors

1. Sending `+1 555 123 4567` to a system that wants E.164

The spaces are not legal in E.164. Strip them: +15551234567.

2. Sending `+15551234567` to a UI field that expects local display

The user sees +15551234567 instead of +1 555 123 4567 and reports it as a bug. Format on display.

3. Mixing the two in a single column

Half your contacts in E.164, half in the spaced form. Deduplication breaks because +15551234567 and +1 555 123 4567 are different strings. Normalise everything to E.164 before deduplication.

What About `+1-555-123-4567`?

The dashed form is informal. It is not E.123 notation (E.123 prefers spaces) and it is not E.164 (digits-only). It is the North American phone-number convention bleeding through.

Most phone-number libraries parse it correctly because they strip non-digit characters before validation. But if you are storing it as canonical, you are storing a third variant — which means three deduplication misses instead of one. Convert to E.164 and store that.

The `+` vs `00` vs `011` Question

The + prefix is part of both E.164 and E.123. It is not the digits "00" (the European IDD prefix) or "011" (the North American IDD prefix). Numbers stored as 00447911123456 or 01144791112345 are using the dialling prefix specific to one origin country instead of the location-independent +.

+447911123456    ✓ E.164
00447911123456   ✗ uses European IDD instead of +
01144791112345   ✗ uses North American IDD instead of +
447911123456     ✗ missing the + entirely

Replace any IDD prefix with +. The converter on this page does the substitution automatically.

Hybrid Forms You Will See in the Wild

| Form | What it is | | --------------------- | ---------------------------------------------------------------------------------------------------------------------------- | | +1 (555) 123-4567 | North American convention with + prefix — neither E.164 nor strict E.123 (E.123 prefers spaces over dashes). | | (555) 123-4567 | National notation — local within North America, ambiguous internationally. | | +44 (0) 7911 123456 | UK convention showing both the international and trunk forms — informational only, not valid for either standard as written. | | tel:+15551234567 | RFC 3966 URI — the canonical format for click-to-call links and contact data interchange. |

For each, the underlying number digits are recoverable, but only the strict E.164 form (+15551234567) is suitable for storage and APIs.

RFC 3966 — The Third Format You Should Know

If you have ever seen a phone number in a tel: URI — tel:+15551234567 — that is RFC 3966, the IETF specification for phone-number URIs. It is built on top of E.164 and used wherever a phone number needs to be a clickable link:

HTML <a href="tel:+15551234567"> for click-to-call on mobile pages
vCard contact files
WebRTC / SIP signalling

RFC 3966 is essentially "E.164 wrapped in tel:" with optional URI parameters (;ext=, ;phone-context=). The converter on this page outputs the RFC 3966 form alongside E.164 and the human-readable international form.

When the Distinction Genuinely Does Not Matter

If you are:

Manually dialling from a smartphone (the dialler strips formatting)
Calling from a softphone with smart parsing
Pasting into a contact form that runs libphonenumber on the client

…then any of +1 555 123 4567, +1-555-123-4567, or +15551234567 will work. The distinction matters when you cross into a system that does not normalise: APIs, databases, telephony backends.

Practical Rule of Thumb

Store E.164. Display international.

One canonical string per number, written in strict E.164. Format on display for humans.

The converter at the top of this page outputs both forms side by side — paste any number, copy whichever you need.

Related Guides

Bottom Line

E.164 is the digits-only machine format APIs require. The "international format" most documentation and people refer to is the human-readable E.123 notation with spaces. They represent the same number but are different strings — and "different strings" is what causes deduplication failures, API errors, and integration bugs. Store E.164, render international, and use the converter on this page when you need to move between the two.