Normalize phone numbers in CSV to E.164
Phone numbers in CSV exports come in dozens of formats: (415) 555-2671,
+1-415-555-2671, 4155552671. Upload your CSV and CSViser
normalises every phone column to E.164 (+14155552671) — the format expected
by Twilio, Mailchimp, Salesforce, and most CRMs.
Upload your CSV with phone numbers
CSV, XLSX, or JSON — any size
Free account — takes 10 seconds to sign up
After upload: go to Convert data tab → select Phone number for the phone column → Check → Convert.
What is E.164 format?
E.164 is the international telephone numbering standard defined by the ITU. A number in
E.164 format starts with a + sign, followed by the country code, then the
national number — no spaces, dashes, parentheses, or dots. Examples:
+14155552671— US number (country code 1)+447911123456— UK number (country code 44)+380441234567— Ukraine number (country code 380)+491701234567— German number (country code 49)
This format is unambiguous globally — no guessing about whether 0441234567
is a UK number starting with the trunk prefix 0 or an Australian number.
Twilio, WhatsApp Business, Salesforce, HubSpot, and Klaviyo all require E.164 for
programmatic use.
Why phone numbers in CSVs are messy
Phone numbers are typically entered by humans, not software. A contact form might accept
(415) 555-2671 or 415.555.2671 or +1 (415) 555-2671 —
all valid to a human reader, all different strings to a parser. When you export a CRM,
collect form submissions, or receive a vendor file, the phone column reflects whatever
format the original entry used. A dataset of 5,000 contacts might contain 20 distinct
formatting styles for the same country.
Local numbers (without a country code) are particularly tricky: 4155552671
could be a US number or any number of other countries. CSViser handles this by asking you
to specify a default country for local numbers — it then applies the country's dial prefix
where the country code is missing.
What gets validated and what gets normalised
CSViser uses the libphonenumber library (the same library used by Google
and Android) via the Ruby phonelib gem. For each value in the selected column:
- If the number is valid and parseable → normalised to E.164 in the output
- If the number is invalid (wrong digit count, impossible prefix) → left unchanged
- If the cell is empty → left empty
After clicking Check, CSViser shows how many values are valid (and will be normalised) and how many are invalid (with the first 10 shown as examples). You can optionally clear all invalid values — replacing them with empty cells — before downloading.
Frequently asked questions
What if my file has phone numbers from multiple countries?
Numbers that already include the country code (i.e. start with + or 00)
are parsed correctly regardless of the default country setting. Only local numbers without
a country code fall back to the default. If your dataset is truly multinational, the best
approach is to ensure all numbers already have their country code before normalising.
Does this work for SMS shortcodes?
Shortcodes (e.g. 12345) are not valid E.164 numbers and will be flagged
as invalid. Shortcodes are carrier-specific and not internationally standardised —
they are usually stored as plain text rather than normalised.
Can I validate without converting?
Yes. Click Check to see the validation results and the list of invalid numbers, without applying any changes. Use Convert only when you're ready to normalise the valid numbers.