How to Convert Phone Numbers to E.164 Format (The Complete Guide)

If you have ever tried to send SMS messages through Twilio, push contacts into AWS SNS, or integrate phone data with any modern API, you have almost certainly hit this wall: "Invalid phone number format." The fix is almost always the same. Your phone numbers need to be in E.164 format. This guide explains exactly what E.164 is, why every major platform demands it, how to convert your numbers manually, and why that manual approach falls apart the moment you have more than a handful of records.

What Is E.164 Format?

E.164 is an international telephone numbering standard defined by the ITU (International Telecommunication Union). It provides a globally unique identifier for every phone number on the planet. The rules are simple:

• Starts with a + (plus sign)
• Followed by the country code (1 to 3 digits)
• Followed by the subscriber number (national number without trunk prefix)
• Maximum 15 digits total (not counting the +)
• Contains only digits after the plus sign — no spaces, dashes, parentheses, or dots

For example, a US mobile number like (415) 555-1234 becomes +14155551234 in E.164. A UK number like 07911 123456 becomes +447911123456. A German number like 030 1234567 becomes +49301234567. The pattern is always the same: strip everything that is not a digit, remove the trunk prefix (the leading 0 or 1 used for domestic dialing), prepend the country code, and prepend the plus sign.

Why APIs Require E.164

Every major communications platform mandates E.164 because it eliminates ambiguity. Without a standard format, the number 07911123456 could be a UK mobile or an entirely different number in another country. Here is a quick look at what the big platforms say:

• Twilio: All phone numbers passed to the Messages API must be in E.164. Non-compliant numbers are rejected outright.
• AWS SNS: The PhoneNumber parameter for SMS publish requires E.164. No exceptions.
• MessageBird: Both originator and recipient must follow E.164 in their REST API.
• Vonage (Nexmo): E.164 required for all voice and messaging endpoints.
• Salesforce: While not strictly required for storage, Salesforce integration tools and CTI adapters expect E.164 for click-to-dial and SMS features.

The bottom line: if you are working with phone data that touches any API, E.164 is not optional. It is the lingua franca of telephony.

Common Input Formats and Their E.164 Equivalents

Phone numbers arrive in your spreadsheets and CSVs in dozens of formats. Here is a before-and-after table showing eight of the most common input patterns and what they should look like after conversion:

Manual Conversion Steps

If you only have a few phone numbers to convert, you can do it by hand. Here is the general process:

1. Strip all non-numeric characters. Remove parentheses, dashes, spaces, dots, and any other punctuation. Keep only the digits and any leading plus sign.
2. Identify the country. If the number already starts with a country code (like 1 for US/Canada, 44 for UK), note it. If it starts with a trunk prefix (like 0 for UK or Australia), you will need to know the country to proceed.
3. Remove the trunk prefix. In the UK, drop the leading 0. In some countries, drop the leading 0 or other domestic dialing prefix.
4. Prepend the country code. Add the numeric country code to the front of the subscriber number. US/Canada is 1, UK is 44, Germany is 49, Australia is 61, Brazil is 55, India is 91.
5. Prepend the + sign. Place a literal plus character at the very beginning.
6. Validate the length. The total number of digits (after the +) must not exceed 15. Most national numbers are between 10 and 13 digits including the country code.

Why Manual Conversion Fails at Scale

The manual process works fine for 5 numbers. It is tolerable for 50. It is a nightmare for 5,000, and it is genuinely impossible for 50,000 or more. Here is why:

• Mixed countries in one column. Real-world data does not come neatly labeled by country. A CSV exported from HubSpot, Salesforce, or a webform might contain US, UK, Australian, and Indian numbers all jumbled together with no country indicator.
• Inconsistent formatting within a single country. Some entries have dashes, others have spaces, others have parentheses, and some are already partially formatted. You cannot apply a single find-and-replace rule.
• Excel mangles your data. If you open your CSV in Excel to clean it, Excel will silently strip leading plus signs, drop leading zeros, or convert long digit strings to scientific notation. You end up worse off than when you started.
• Trunk prefix ambiguity. The number 0412345678 could be an Australian mobile or something else entirely. Without country metadata, you are guessing.
• Error rates compound. Even a 1% error rate on 50,000 numbers means 500 failed deliveries, 500 wasted SMS credits, and potentially 500 angry customers who did not get the message they were supposed to receive.

How NoSheet Converts Phone Numbers to E.164 Instantly

NoSheet was built specifically for this kind of data cleaning problem. Instead of wrestling with Excel formulas, Python scripts, or regex patterns, you can convert an entire column of phone numbers to E.164 in seconds. Here is how it works:

1. Upload your CSV or Excel file. Drag and drop or click to upload. NoSheet reads your file directly in the browser — your data never leaves your machine.
2. Select your phone number column. NoSheet auto-detects columns that look like phone numbers and suggests them for formatting.
3. Choose "Format to E.164." Pick the default country code for numbers that do not already include one. Numbers that already have a country code or + prefix are handled automatically.
4. Preview and download. NoSheet shows you a before-and-after preview so you can verify the conversion. When you are satisfied, download your clean file.

NoSheet handles all the edge cases that break manual workflows: mixed countries, inconsistent delimiters, leading zeros, trunk prefix removal, and length validation. It processes tens of thousands of rows in under a second, and because everything runs client-side, your phone data stays private.

Real-World Use Cases

E.164 conversion is not just a niche developer problem. Here are the most common scenarios where people need this:

• Twilio SMS campaigns. You have a marketing list of 20,000 contacts from a trade show. The phone numbers are in every format imaginable. Twilio will reject anything that is not E.164.
• Salesforce data imports. Your sales team collected leads across multiple countries. Before you can import them into Salesforce and trigger automated SMS follow-ups, every number needs to be standardized.
• CRM migration. Moving from HubSpot to Salesforce or vice versa. Phone number formats differ between platforms, and you need a clean, consistent format before the migration.
• AWS SNS notifications. Setting up transactional SMS (order confirmations, OTP codes). SNS strictly requires E.164 and will silently fail on anything else.
• Contact list deduplication. You cannot deduplicate phone numbers if they are in different formats. (415) 555-1234 and +14155551234 look different to a naive dedup, but they are the same number. Standardizing to E.164 first makes dedup accurate.

Tips for Maintaining E.164 Going Forward

Once you have cleaned your phone numbers, keep them clean:

• Validate at the point of entry. Use input masks on your web forms that enforce E.164 format. Libraries like libphonenumber can validate and format in real time.
• Store in E.164, display in local format. Your database should always contain the E.164 version. Format for display only at the presentation layer.
• Never open phone CSVs in Excel. Use NoSheet or a text editor. Excel will destroy your formatting before you even realize it.
• Include country context in your forms. A country dropdown next to the phone field lets you capture the country code at input time instead of guessing later.

Related Resources