CSV Phone Number Format and E.164 Import FAQ

E.164 is the standard international phone-number format: a plus sign (+), country code, and subscriber number without spaces or local formatting characters. Many CRMs, dialers, and APIs prefer it because it is consistent and machine-readable. For a full walkthrough, see what E.164 phone number format means.

For many CRM, dialer, and API imports, E.164 is the safest format to target. In practice that means a plus sign followed by the country code and subscriber number, with no spaces, dashes, or parentheses. The exact import columns may vary by platform, but E.164-style formatting is usually the most portable starting point.

Upload your CSV, choose the phone column, and optionally map a country column or set a default country. Then process the file so safe rows can be normalized to E.164 while unclear rows go to a separate needs-review file. You can see the full workflow on How It Works.

Provide country context. You can set a default country for the whole file or map a country column if your CSV includes one. Without country context, local-format numbers may be ambiguous, which is why some rows are sent to review instead of being guessed.

If your CSV includes a country column, map that column so local-format numbers can be interpreted row by row. Numbers already starting with + are already international and can be parsed directly. Mixed-country CSVs are much safer when the country column is present and correctly mapped.

“Needs Review” means the tool found phone data it should not normalize automatically. Common reasons include missing country context, ambiguous local numbers, extensions, multiple numbers in one cell, or extra notes in the phone field. Separating these rows protects the cleaned CSV from risky guesses.

A number can be marked invalid when it fails structural or numbering-plan checks after parsing. In practice this often means the field is empty, too short, too long, or still not a valid phone number even after country context is applied.

E.164 does not include extensions inside the main phone number field. When an extension is detected, the row is sent to review so the core number and the extension can be handled separately if needed.

The tool does not guess which number you want to keep. If more than one phone number appears in the same cell, that row should go to the needs-review file for manual cleanup.

No. The normal workflow processes your CSV locally in the browser using JavaScript. The file and its contents are not uploaded to a server as part of the core tool flow. For more detail, see the Privacy Policy.

For Google Contacts imports, international formatting with country code is the safest direction. This tool can help clean a messy phone column toward E.164-style output before import, but you should still verify the destination columns and final import expectations inside Google Contacts.

For HubSpot imports, E.164-style formatting is often the safest target for phone fields. This tool helps clean a messy CSV phone column toward that format, but it does not directly integrate with HubSpot and you should confirm the final import requirements in your HubSpot setup.