Convert CSV to XLSX — auto-typing pitfalls, ZIP codes, and large-file performance

The short version

1. Drop your .csv on the converter. We detect the delimiter (comma, semicolon, tab, pipe) and encoding automatically.
2. Review the 20-row preview. We'll show inferred types per column (Text, Number, Date, Boolean).
3. Override any column where the auto-type is wrong — especially Text for ZIP codes, SKUs, phone numbers, IDs, and anything with a leading zero.
4. Pick a date format if your CSV has dates (ISO 2022-01-01 is our default; Excel will display them in the user's locale).
5. Download a single .xlsx. One sheet, one header row, everything rendered correctly.

That's the happy path. The rest of this post is for when your leading zeros vanished, when your dates got flipped, when Excel refused to open the file because it was "too large," or when your accented characters became mojibake.

The auto-typing problem — Excel's three famous bugs

When Excel opens a CSV via double-click, it runs a silent type inference pass per column. That pass is convenient for numeric data and catastrophic for three specific categories:

Leading zeros — the ZIP-code, SKU, and phone-number problem

A column of US ZIP codes like 05401 (Burlington, Vermont) is text. Excel reads "05401," sees digits, infers "Number," stores it as 5401, and the leading zero is gone. Same problem: SKUs like 007-AB where the first few characters are digits; phone numbers with leading zeros (020 7946 0958 → 2079460958); German tax IDs; any identifier that looks numeric but is semantically a string.

The only real fix is to declare the column Text at import time. Our converter lets you do that before the XLSX is generated, so the cells are stored as text in the XLSX itself — no re-inference on the receiving end.

Dates — the US-vs-EU flip

"1/4/22" is either January 4, 2022 (US reading) or April 1, 2022 (UK / EU reading). Excel picks based on the user's OS locale when it parses. If the CSV was generated by a US tool and opened by a UK analyst, every date in the file is silently shifted.

The fix is to use ISO 8601 (2022-01-04) in the source CSV whenever you have a choice. It's unambiguous — year first, month second, day third, always. Our CSV-to-XLSX preserves the underlying date value and writes the XLSX with a proper date cell type, so Excel displays it in the user's locale from the correct source.

Long IDs — the 16-digit silent rounding

Excel stores numbers as IEEE 754 doubles — 15 decimal digits of precision. A 16-digit credit-card number, a 17-digit bank reference, a 19-digit tracking code: all get rounded to 15 digits once Excel infers "Number." A 4532015112830361 becomes 4532015112830360. Silently. No warning.

Fix: Text. Always Text for IDs, no matter how numeric they look.

Delimiter detection — and when it fails

A well-behaved CSV uses one delimiter consistently. Real-world CSVs are less tidy. Our detector samples the first ~2 KB, counts commas, semicolons, tabs, and pipes per line, and picks the delimiter that gives the most consistent column count across the sample. That works for ~99% of files.

The 1% where it fails: files with a mix of quoted and unquoted commas, files where the first few rows have different column counts (a preamble or a merged-cell remnant from an Excel export), and files where the delimiter appears inside unquoted cells. For those, we expose a manual picker and show a 20-row preview so you can see the split change in real time.

UTF-8 BOM and encoding — why your accents look weird

If you convert a CSV with French (é), German (ü), Spanish (ñ), or any CJK text and the resulting XLSX shows é, ü, or ä½ å¥½, the CSV was misread as a different encoding. The fix is to tell the converter the source encoding up front.

Our detector looks for:

• BOM (EF BB BF) — the file declares UTF-8.
• BOM (FF FE / FE FF) — UTF-16 LE / BE.
• No BOM, valid UTF-8 byte sequences — read as UTF-8.
• No BOM, invalid UTF-8, high-bit bytes in the Windows-1252 range — fall back to Windows-1252.

You can override via the encoding picker if the detector guessed wrong. This matters most when the CSV came from a legacy Windows Excel export that wrote Windows-1252 without a BOM — a very common case and the #1 cause of "why does my XLSX have garbage characters" reports.

Large CSVs and Excel's row cap

Excel's sheet-size limit is 1,048,576 rows × 16,384 columns per sheet. If your CSV has more rows than that, Excel truncates silently on import — you lose the tail without any warning.

We handle this up front. If the row count exceeds the cap, we offer three options:

• Split into multiple sheets — 1 M rows per sheet, same headers repeated, sheets named Sheet1, Sheet2. Works for up to ~16 sheets comfortably.
• Split into multiple XLSX files — if the data is too big for even a multi-sheet workbook, zip of multiple XLSX files.
• Don't convert — consider a different tool — at 5 M+ rows, XLSX is the wrong answer. Stick with CSV / Parquet / DuckDB.

Our in-browser XLSX writer streams rows, so a 800 k-row CSV doesn't hold everything in memory at once — it writes XLSX's internal XML progressively and zips at the end. Most modern laptops handle up to ~500 k rows comfortably; the wall is RAM, not format.

Headers, empty rows, and the "first row is a title" problem

Many CSVs exported from BI tools or scraped from web tables have a decorative first row: a title, a date-stamp, or merged metadata. Excel treats it as the header row, which gives you one giant column and a mess.

Our preview lets you pick which row is the header (row 1, row 2, etc.), skip blank rows, and drop empty trailing columns. This is the difference between "clean XLSX, ready for pivot tables" and "I'm about to manually delete ten rows" on the receiving end.

How our tool compares (honestly)

CSV-to-XLSX is a solved problem on paper and a mess in practice. What matters is type control, large-file handling, encoding detection, and not uploading your sales data to a random server. Honest scoresheet:

Honest summary: if you script, pandas with explicit dtype=str is the gold standard. If you already own Excel, use "Data → From Text/CSV" (not double-click) and set types manually. For everything else — especially privacy-sensitive data, million-row CSVs, or the common ZIP-code and leading-zero problem — our CSV to XLSX converter is the short path with the override built in.

Where our tool works well — and where it doesn't

Works well

• Mixed-typed CSVs with ZIP codes, phone numbers, SKUs, and dates that must survive the round trip intact
• UTF-8 and legacy Windows-1252 CSVs — auto-detected, override available
• Medium-large CSVs (up to ~800k rows) in a single session
• Privacy-sensitive data (stays in your browser; no upload)
• Chains cleanly from JSON to CSV (API response → CSV → XLSX for distribution)

Doesn't work (well) yet

• Massive CSVs (>5 M rows) — we split into multiple sheets, but Excel itself becomes painful past that
• CSVs that are actually broken — ragged-column counts, mismatched quotes mid-file, binary data embedded. A reasonable parser only recovers so much; use a data-cleanup script first.
• Generating formulas — we paste values, we don't generate SUMs or lookups. Build those in Excel after.
• Preserving non-standard features from whatever produced the CSV — styled row colors, frozen panes, conditional formatting. CSV doesn't carry those; we can't invent them.

Tips for the best result

• Declare Text for every ID column. ZIP codes, SKUs, product codes, phone numbers, account numbers. The default auto-type is wrong for all of these.
• Prefer ISO-8601 dates in the source CSV. 2022-01-04 is unambiguous; 1/4/22 is not.
• Check the 20-row preview before you download. That's where the leading-zero / date-flip / rounding bugs show up; catching them there is free.
• If the source is a JSON API response, go JSON → CSV first. Our JSON to CSV converter handles nested objects; then drop that CSV here for a clean XLSX.
• For very large exports, prefer multi-sheet over multi-file. A 2-sheet workbook is friendlier to pivot tables than two separate XLSXs.
• Need the reverse? XLSX to CSV is the other direction — different gotchas (sheet selection, delimiter, encoding) but the same five-decision framework.

Common questions

My ZIP codes lost their leading zero. How do I fix it?

Set the ZIP column to Text in our column-type picker before downloading. If you've already downloaded and Excel destroyed the zeros, you have to re-run the conversion — Excel can't recover the zero after the fact (it doesn't know whether 5401 was originally 5401 or 05401).

Why does Excel complain about "file too large" on import?

Because the CSV has more than 1,048,576 rows — Excel's hard sheet cap. Our converter offers multi-sheet output (1 M rows per sheet) to sidestep that, or you can split into multiple XLSX files. At that data size, consider whether XLSX is the right format at all; CSV, Parquet, or DuckDB are friendlier for multi-million-row datasets.

My CSV uses semicolons, not commas. Will the converter figure it out?

Yes — we auto-detect the delimiter by sampling the first couple KB and picking the one that gives the most consistent column count. You can override manually if the detection is wrong.

My accented characters show up as garbage (é, ü). What happened?

The source CSV was written in Windows-1252 (or another legacy 8-bit encoding) and our detector guessed UTF-8. Re-run the conversion and pick Windows-1252 manually in the encoding dropdown. Going forward, ask whoever generated the CSV to write UTF-8 with BOM — it's the modern default and interoperates cleanly with Excel on Windows.

Will my XLSX open in Google Sheets or Numbers?

Yes — we write standard Office Open XML (ISO/IEC 29500). Every mainstream spreadsheet app reads it. The data types survive the cross-app opening because we wrote them into the XLSX cell types (Text stays Text, Date stays Date), not just as formatted display.

Do my files get uploaded to your server?

No. We parse the CSV in your browser (a streaming parser that doesn't hold the whole file in memory) and write the XLSX in your browser too. Your data never leaves your machine. Paid tiers raise the per-file caps but use the same browser-side path.

Is this tool really free?

Yes. No watermark, no daily cap, no sign-up on the free tier. Paid tiers lift the per-file size ceiling for very large CSVs and add an API endpoint for batch jobs.

Ready?

CSV to XLSX →. Drop the CSV, set column types, download the XLSX. Free, in your browser, no sign-up, no watermark. Need the reverse? XLSX to CSV. Coming from an API? JSON to CSV is the upstream step.