CSV or XLSX for a phone-number import?
Choose the safer export format for your next CRM or spreadsheet workflow and avoid accidental formula or zero changes.
XLSX is usually the safer choice when you need exact text cells and human review. CSV is useful when a destination requires it, but spreadsheet programs may reinterpret values beginning with +, =, @ or -. E164Flow offers explicit export choices for both situations.
How do I start this workflow?
Keep the source file, confirm the phone and country fields, and review the results before choosing the import layout.
- Choose XLSX when a human will review the file or leading zeros matter.
- Choose spreadsheet-safe CSV for general-purpose sharing.
- Choose CRM CSV-E164 only after checking the destination’s text-import behaviour.
Can the same phone value look different in different exports?
Yes. The export choices protect or preserve values for different destinations. Check the file mode as well as the phone format before deciding that an extra character is an error.
| Export choice | Generated E.164 value | Intended handling |
|---|---|---|
| XLSX | +442079460018 in a text cell | Spreadsheet review with exact text |
| Spreadsheet-safe CSV | '+442079460018 | Apostrophe protects spreadsheet interpretation |
| CRM CSV | +442079460018 | Import generated canonical phone fields directly |
The apostrophe shown for spreadsheet-safe CSV is an export protection, not part of the E.164 number. CRM CSV preserves + in generated phone fields, while original source fields and headers remain escaped. An original field does not become trusted phone output simply because you rename its header.
When is XLSX the better file to download?
Choose XLSX when a person needs to review the file in a spreadsheet or when exact text cells are important. E164flow writes the exported values as text rather than spreadsheet formulas.
This is useful for record IDs with leading zeros, phone values beginning with + and extension fields whose zeros matter. Keep the original ID beside the generated output so a reviewer can follow a correction back to the source contact. A clean-looking phone column without its identifying fields may be difficult to use safely for an update.
An XLSX file still needs a destination check. Select the intended sheet and map the fields in the importing system, then compare a small sample of the resulting records. A typed spreadsheet cell helps preserve representation; it does not tell the CRM which existing contact should be updated.
Why can a CSV change when I open it in Excel?
A CSV is text separated into records and fields, not a workbook carrying spreadsheet cell types. The program opening it may decide how to interpret the values.
Microsoft documents Excel's handling of leading zeros and large numeric-looking values. Phone numbers and record IDs can be affected by those interpretations. Merely seeing the right digits in a converter preview does not guarantee that a later open-and-save step in another program will preserve them.
Review an exact CRM CSV as text or use the converter's file preview, and use an XLSX report for a human spreadsheet check. If someone has already opened and resaved the CSV, compare its contents with the original export before importing it. Do not assume that adding quotation marks alone gives CSV values a persistent text-cell type.
How are spreadsheet-safe CSV and CRM CSV different?
Spreadsheet-safe CSV protects values that could be interpreted as formulas. CRM CSV preserves the plus sign in generated canonical phone fields for a direct machine import.
A value beginning with + can therefore receive an apostrophe in the spreadsheet-safe export. That is expected protection for the chosen file purpose. It can be unsuitable if the receiving system imports the apostrophe literally, which is why the destination's preview needs to be part of the decision.
The CRM-specific choice has a narrow exception for generated phone output. Original fields and headers remain escaped, even if a source column is called E164 or is renamed in the export editor. Keep that distinction when building a custom layout, and avoid copying unreviewed source text into a generated field outside the converter.
What should I check about separators, encoding and headers?
Check that the file opens into the expected columns and that names and other source text display correctly. For input files, review the selected separator, encoding and header row where those choices apply.
A semicolon-separated file interpreted as comma-separated text can appear as one large field. A report title above the actual table can be mistaken for the header. Resolve those structural issues in the import preview before choosing phone and country fields; formatting a misread column does not fix the file's structure.
CSV also needs consistent handling of embedded separators, quotes and line breaks. E164flow's export produces the file rather than asking you to join cells with commas manually. When a destination requires CSV, test the actual downloaded file and its importer settings, especially if the source contains international names or multi-line notes.
How do custom columns and several phone fields affect the export?
Choose the source ID and each required generated phone or extension field, then check their names and order in the preview. Several phone columns can remain on one contact row.
The CRM columns shortcut supplies a focused starting layout, while Customize export columns lets you keep, remove, rename and reorder fields. Keep the selected record ID when updating existing contacts. A friendly header name does not establish that its values are the identifier the destination expects.
Check the export selection as well as the layout. Ready, unique, filtered and full-report choices can produce different sets of results. On an included multi-column contact row, an excluded phone cell has blank generated output for that field. Compare contact rows rather than expecting the number of phone-cell results to equal the number of exported contacts.
What is the final check before handing the file to a CRM?
Test a small sample in the actual destination and compare the same identifiers and phone fields after import. The extension, plus sign and source ID should mean what you intended.
Include a source ID with significant formatting, an international number, a national number that required country context and an extension example. Check for unexpected new records, skipped rows or a phone value imported into the wrong field. Keep a full review report separately if the final import layout intentionally omits warnings and original values.
A local profile can save an export layout for the next file, but it does not save contact rows or guarantee that the next workbook has the same fields. Review each new file. Free accounts support uploads and exports up to 50 rows per file; Pro supports up to 20,000. Both formats use the same browser-local conversion path.
Which primary sources support this workflow?
Use the underlying standard or the destination's own documentation when checking a numbering rule or an import requirement.
What should I check before the final import?
Compare a small sample with the source and the destination, then use this checklist to review the complete file.
- Do not use a spreadsheet to preview and resave a CRM CSV without checking the values.
- Keep a copy of the original file outside the converter.
- Review the export row count and the invalid/duplicate filters before upload.
Start with the data you have.
Use 25 pasted rows without an account, or sign up for the 50-row free workflow with CSV/XLSX and export.