Someone has asked for "the Excel file" and what you have is a .csv, on your
phone, in an email. The conversion itself is easy — three or four taps on either
platform. The part that goes wrong is what the conversion does to your values on
the way through.
The fast answer
On iPhone or iPad: Files → long-press the CSV → Share → Numbers → open it → ⋯ → Export → Excel.
On Android: upload to Drive → Open with → Google Sheets → ⋯ → Share & export → Save as → Excel (.xlsx).
Both, with either app you already have Microsoft 365 on: open the CSV in Excel for iOS/Android and Save As → .xlsx.
Then — and this is the whole reason this page is longer than four lines — check the ID, postcode and date columns before you send it.
What "converting" actually does
A CSV stores values as characters and nothing else. An XLSX stores a type for every cell. So converting isn't a re-wrapping; it is a program deciding, for each column, what your data means. It decides consistently, and consistently wrongly in four places:
| In the CSV | After conversion | Recoverable? |
|---|---|---|
01923 (postcode) | 1923 | Only from the original |
4019283746501928 (ID) | 4.01928E+15 | No — digits are gone |
03/04/2026 | 3 April or 4 March, by locale | Sometimes |
MAR1 (gene, part code) | 01-Mar | Sometimes |
+1 (555) 010-9999 | 15550109999, or a formula error | Sometimes |
The scientific-notation row is the one that actually hurts. Excel carries 15 significant digits; a 16-digit order number or credit reference is truncated, not merely displayed oddly. Widening the column does not bring it back.
More on why in CSV vs XLSX. The practical upshot for a phone conversion is: know which of your columns are codes rather than numbers, before you start.
Route 1: iPhone and iPad, with Numbers
Numbers is a free download from Apple and is the shortest path on iOS.
- Save the file to Files first. If it is a Mail attachment, long-press → Save to Files. Mail's preview is a sandboxed copy and edits there go nowhere.
- In Files, long-press the CSV → Share → Numbers. It imports and opens
as a
.numbersdocument. - Fix anything the import mangled — see the checks below.
- ⋯ (top right) → Export → Excel. Choose whether to include a summary
worksheet, then share the resulting
.xlsx.
Limits worth knowing: Numbers caps at 1,000,000 rows and 1,000 columns and slows down long before either. Above roughly 100,000 rows this becomes an exercise in patience.
The one trick that prevents the damage: you cannot pre-set column types on import in Numbers. What you can do is fix a column afterwards — select it, then Format (paintbrush) → Cell → Data Format → Text — and retype the affected values. That is fine for a handful and hopeless for thousands, which is why the next section exists.
Route 2: Android, with Google Sheets
- Upload the CSV to Google Drive.
- Open with → Google Sheets.
- ⋯ → Share & export → Save as → Excel (.xlsx). The file lands in Drive alongside the original.
Limits: 10 million cells per spreadsheet — rows × columns, so a 40-column export runs out at about 250,000 rows. The whole file uploads first, which on cellular is the slow part, and it means the data leaves the device.
Sheets applies the same type inference as everything else. Its saving grace is Format → Number → Plain text applied to a column before you export, which at least stops the export re-mangling what you fixed.
Route 3: Excel for iOS and Android
If you have Microsoft 365 already, this is the highest-fidelity route, because Excel's conversion is the one the recipient's Excel will agree with.
Open the CSV in the app, then File → Save As → Excel Workbook (.xlsx).
Limits: editing requires a subscription on any device over 10.1 inches (so: iPads, most Android tablets — phones are free). The mobile version has no equivalent of the desktop Text Import Wizard, so you still cannot set column types on the way in. Same problem, better-known name.
Route 4: prepare the file first, then convert
The routes above all have the same weakness: type damage happens at import, and every fix is a repair after the fact.
Working in an app that keeps the file a CSV — no import step, no inference — lets you sort out what you're actually sending before handing it to a spreadsheet.
Reads the file as a CSV rather than importing it, so values arrive as written — then SQL, visual filters or a plain-language question tell you which columns are codes before anything reinterprets them.
What it doesAnd when the fix is an edit rather than a check — dropping the columns nobody asked for, correcting rows, adding a computed column — doing it on the CSV means one conversion at the end instead of a conversion, a repair, and a re-export.
Spreadsheet-style editing on iPhone and iPad with formula columns, Excel-style filters, and every row preserved on save — so what reaches the converter is already the file you meant to send.
What it doesBefore you send it: four checks
Thirty seconds, and they catch essentially every conversion failure:
- Row count. Does the converted file have as many rows as the CSV? If the converting app truncated, this is where you find out.
- The ID column. Scroll to a long one. Anything showing
E+has lost digits permanently. - Leading zeros. Postcodes, product codes, account numbers, anything
beginning
0. - One date, checked against a known record. March 4th and April 3rd look equally plausible in isolation.
When not to bother
If the recipient is going to import your file into another system anyway, ask
whether they actually need .xlsx. Most import pipelines prefer CSV, and every
conversion is a chance to lose something. "Here is the CSV, the ID column is
text" is often the better answer than an Excel file with 27 broken order
numbers in it.