CSV to XLSX Converter

You know the photo before we describe it. A spreadsheet with exactly one column, eight hundred rows long, each cell a whole crushed record — name, comma, address, comma, order number — staring back at you like a mouthful of teeth. Double-click the CSV, watch Excel shrug, and spend the next twenty minutes finding Data > From Text, guessing delimiters, and losing your leading zeros along the way.

Sometimes the failure is more decorative. The file opens, splits into columns, and the customer names arrive as Jürgen and Žofia — mojibake, the classic sign of UTF-8 text being read as a legacy code page. Or the ZIP code 02134 loses its zero and becomes 2134, and a Boston mailing list quietly acquires a Cambridge one.

None of this is your fault, exactly. CSV is a plain-text convention with no type information, no encoding declaration, and no statement of its delimiter. Excel fills every one of those gaps with a guess, and guesses calibrated to your regional settings at that. The format itself is fine — RFC 4180 is a four-page read — but a naked text file and a spreadsheet application have fundamentally different ideas about what should happen on open.

This converter refuses to guess. It sniffs the delimiter from the data, detects types per column, writes a real Office Open XML workbook with typed cells, adds the UTF-8 byte-order mark that makes Excel behave, and hands you a download that opens correctly on the first double-click. The whole thing runs in your browser, which — given that CSVs are usually full of customers, employees, or patients — is exactly where it should run.

If you are headed the other direction, feeding a spreadsheet into a pipeline that wants CSV, the XLSX to CSV Converter is built for that trip, with per-sheet export and the same local processing. Both tools exist because the two formats keep being mistaken for each other, and the collision is never pretty.

The workflow is deliberately short — the tool is a corridor, not a lobby. Six steps, none of which involve a wizard with a preview grid from 1992.

1. 1

   Load your CSV

   Drag the file in or paste the raw text. The parser reads it locally through the browser's file interface, handles quoted fields, and reports the detected delimiter and row count back to you before anything is written.

2. 2

   Confirm the delimiter

   Auto-detection is the default and is right nearly always — comma, semicolon, and tab are ranked by how consistently they divide the rows into a matching column count. Override it from the dropdown if your data disagrees with the vote.

3. 3

   Check the typed preview

   Columns are classified as text, number, or date from their contents, and the preview shows the result. ZIP codes and other label-like digit strings are held as text on purpose, so zeros survive the trip.

4. 4

   Pick the finishing touches

   The output workbook can include a frozen header row and an autofilter on the columns — small things that make a five-hundred-row workbook usable on arrival instead of after ten minutes of manual formatting.

5. 5

   Convert and download

   The .xlsx is assembled in memory and saved straight from the browser. One sheet, your rows, real cell types, UTF-8 with a byte-order mark.

6. 6

   Open it in Excel

   Double-click. Columns split where they belong, accents read correctly, and the zero in 02134 is still employed. That is the entire promise, kept.

The two formats are not variations of one idea — they are different species. A CSV file is lines of plain text with delimiters, defined by convention and, loosely, by RFC 4180. An .xlsx file is a ZIP archive containing an XML document tree: a [Content_Types].xml manifest, a workbook part listing the sheets, one worksheet part per sheet holding rows and cells, a shared strings table for repeated text, and styling parts. The structure is standardized as Office Open XML, maintained by Ecma International as ECMA-376, and it is the same format whether Excel, LibreOffice, or a browser library writes it.

That structure is where the fixes live. Because a cell carries an explicit type, a ZIP code can be stored as text while a price is stored as a number, and neither is a guess. Because styling is a real part of the file, the header row can arrive frozen and the columns can arrive filterable, rather than hoping the recipient does it. And because the encoding story is XML and UTF-8 by definition, the mojibake class of bug simply has nowhere to live in the output.

The conversion itself, then, is honest work rather than a rename: parse the text, infer a type per column, decide which digit-shaped columns are secretly labels, map values into cells, build the package, and zip it. When someone emails you a .csv file with an .xlsx extension — it happens more than you would believe — this tool is also how you find out, because a renamed CSV has no ZIP header and no XML inside.

Here is the quiet scandal behind the one-column screenshot: Excel's CSV delimiter is decided by locale. If your Windows regional settings use a comma as the decimal separator — Germany, France, Brazil, and much of Latin America among them — then the list separator is a semicolon, and Excel opens comma-separated files as a single column. The file is correct. The assumption is regional.

So exports from these regions arrive semicolon-delimited, and colleagues elsewhere open them into the same one-column mess, in mirror image. The sniffing approach sidesteps the whole identity crisis: count how often each candidate delimiter appears outside quoted fields, check that the count agrees across rows, and use the winner. A German CSV full of quoted addresses resolves to semicolon; an American export of the same data resolves to comma; nobody reconfigures their operating system for either.

Quoted fields are the other half of correct parsing, and the rule is compact. Per RFC 4180: a field containing the delimiter, a double quote, or a line break is wrapped in double quotes, and a literal double quote inside a field is doubled. So an address like 12 "The Old" Mill Lane appears as "12 ""The Old"" Mill Lane". Splitting on commas without honoring quotes is how a comment field with one comma becomes two columns and shifts every following cell sideways by one — the most destructive silent bug in spreadsheet-land.

id,name,notes
41,"Okafor, Daniel","Says ""morning"" to everyone"
42,Line,"Quoted field with, commas, inside

A regional coffee chain exports its store list from a scheduling tool. The CSV is below, trimmed to six rows but carrying the classic hazards: a UTF-8 name, a quoted address with commas, a ZIP code with a leading zero, and an ISO date.

Worth noticing what did not happen. The ZIP codes kept their leading zeros because they were classified as text. The addresses kept their internal commas because the quotes were parsed rather than ignored. The é in Café arrived intact because the workbook carries a UTF-8 byte-order mark that Excel trusts. And the dates were written as dates — which means the recipient can sort by them without Excel reinterpreting anything mid-sort.

A decade of CSV-to-spreadsheet support tickets reduces to a short list. Here is the list, with the mechanism behind each entry, because the mechanism is what makes the fix believable.

The date row deserves a warning beyond the fix. Excel's date guessing is genuinely hazardous with two-digit years and slash formats, because 03/04/2026 means March 4 in one country and April 3 in another. ISO format — 2026-03-04 — is unambiguous, sorts correctly as text even when untyped, and is the only date format we would hand to a colleague without flinching. If your source system can export ISO dates, change that setting today.

Limits, stated plainly: a browser converts what memory allows, which in practice means hundreds of thousands of rows are comfortable and the XLSX sheet ceiling of 1,048,576 rows is the hard wall — a CSV larger than that cannot become a single sheet no matter which tool you use. Extremely wide files, thousands of columns, hit the 16,384-column wall first. And if your CSV is actually a report with title rows and footers above and below the table, no converter can know which lines are data; you will need to trim the prologue first.

The converter handles the mechanical failures — delimiters, encoding, quoting, typing. What it cannot do is decide which lines in the file are actually data. A ninety-second inspection before you convert catches the structural problems while they are still cheap, and the checklist is short enough to memorize:

1. Open the file in a plain text editor and confirm the encoding — if names already look wrong there, the file itself needs re-exporting, and no converter can repair information that arrived damaged
2. Check the first line: is it headers, or a title and a timestamp generated by the reporting tool? Prologue rows become data rows unless you trim them
3. Count the columns on the first three data rows and the last row — ragged files usually mean a trailing note, a subtotal line, or an embedded footer that needs deleting
4. Look at one quoted field containing a comma and confirm the quotes are doubled where they should be; a single stray unescaped quote can shift every row after it
5. Note any column that must keep leading zeros — codes, ZIPs, phone numbers — so you can verify them in the preview rather than in tomorrow's mailing

Step one deserves a second sentence, because it is the one people skip. If the text editor shows Jürgen, the file was double-encoded at the source and converting it faithfully just preserves the damage. The fix belongs upstream: re-export with UTF-8 selected, and only then convert. An hour of email chains has started with a conversion of a file that was already broken.

After conversion, one glance at the preview is worth a thousand words of documentation: leading zeros present, accents intact, dates in one column, numbers right-aligned. If those four things are true, the workbook will behave for whoever receives it — which was the entire point of converting instead of forwarding the raw CSV and hoping.

Accountants and bookkeeping staff are the heavyweight users: bank exports, payroll summaries, expense imports — CSVs that must become workbooks with real number cells so that sums sum. E-commerce managers convert platform exports constantly, and their files carry the full house of hazards: SKU codes with leading zeros, product names in five languages, address fields full of commas.

Ops and admin staff receive CSVs from every SaaS tool their company runs — CRM exports, attendance logs, inventory dumps — and the recipient is usually the least technical person in the chain, which is precisely why the failure mode is so costly. Teachers convert grade exports; researchers convert instrument output; small-business owners convert whatever their accountant asked for by Friday.

• Bank and payroll exports that must be summed, filtered, and forwarded
• Store and inventory exports with SKU codes that cannot lose zeros
• CRM and marketing-platform downloads bound for a colleague's spreadsheet
• Any file headed for Excel on a machine with European regional settings
• Lists whose names, cities, or notes contain non-English characters

The unifying motive is dignity of arrival: the file should open correctly for the person who receives it, without that person needing to know what a delimiter is. That standard is low, and yet raw CSVs clear it almost never.

You have options, and they are not equal. We will rank them honestly, including the one where our tool loses.

Where our option loses: very large files that exceed browser memory, and recurring automated imports where the wizard's saved settings or a scripted pipeline genuinely belong. Where it wins: everything else, plus every case where the file contains personal data and should not be uploaded to a converter service in the first place — most of the competing web tools do exactly that, and their privacy policies are the punctuation at the end of that particular sentence.

A CSV-to-Excel converter that uploads your file is a strange bargain: you hand a full copy of your customer list, employee roster, or patient export to an unknown server so it can hand you back a spreadsheet. The data crosses a network twice, sits on someone else's disk for some duration, and the only compensation is that the conversion happened somewhere else. The conversion is not hard enough to justify that.

So this tool is entirely client-side. The file is read by the browser, parsed in the page, typed, packed into Office Open XML, and zipped in memory — then the download link points at the result in the tab, not at a server. You can watch the Network panel while converting: no request carries your rows. You can also go offline after the page loads and convert files on a plane, which doubles as the most persuasive privacy demo we know.

No account, no quota, no file retention policy to read — because there is no file retention. The site's data tools all work this way by design, and the converters are the tools where it matters most.

The reverse trip — XLSX to CSV — handles workbooks headed into pipelines that want plain text, with per-sheet export and a UTF-8 BOM option so the result survives its next encounter with Excel. For the legacy .xls files that still circulate in finance departments, the XLS to CSV Converter reads the old binary format the same way.

And when the destination is not a spreadsheet but an API or a script, the CSV to JSON Converter takes the same local-processing approach and emits structured records instead of cells — the right tool once your data stops being tabular paperwork and starts being a payload.