XLSX to CSV Converter

The CRM import screen is clear about what it wants: a CSV, UTF-8, with headers in the first row. The vendor's export is equally committed to what it sends: an .xlsx file, because that is what their reporting library produces. You are the middleware. Your laptop, meanwhile, belongs to an employer who locks down software installs, so adding a desktop converter means a week of procurement.

Excel itself offers a way out — open the workbook, File > Save As > CSV — and that path is quieter than it looks. It exports only the active sheet, silently. It dates and encodes according to settings you did not choose. It turns formulas into whatever their last calculated value happened to be, which is fine, and formats dates in a locale-dependent style, which is not. Do that across a nine-sheet workbook and the quiet problems add up to an afternoon.

This converter is the direct route: drop the .xlsx in, see every sheet listed, pick one or several, choose your delimiter and encoding, and download clean CSVs with formulas exported as their cached values and dates rendered as real dates. It runs entirely in the browser — no install, no upload, no procurement form.

The privacy angle is not decoration here. Workbooks are dense with the things organizations least want on third-party disks: payroll, pricing, customer rosters, ledgers. A converter that uploads them is asking you to trust an anonymous server with the exact file your compliance training warns you about. This one never sends it anywhere, and the rest of this page explains precisely how.

1. 1

   Drop the workbook in

   Any .xlsx or .xlsm file. The browser unzips the Office Open XML package locally and reads the workbook manifest to enumerate its sheets — names, order, and visibility included.

2. 2

   Pick the sheet

   A multi-sheet workbook becomes multiple CSVs, one per sheet, because a CSV is a single table by definition. Select the sheet you need; the preview shows its first rows before anything is written.

3. 3

   Set the output shape

   Choose the delimiter (comma, semicolon, or tab), and whether to include a header row. For systems that demand European CSV conventions, semicolon is a dropdown away rather than an operating-system setting.

4. 4

   Choose encoding

   UTF-8 is the default, with an optional byte-order mark. The BOM exists for one reason: Excel detects UTF-8 reliably only when it is present, and most CSVs eventually pass through Excel on their way somewhere else.

5. 5

   Convert and download

   Rows stream out with values resolved — formulas to their cached results, dates to formatted dates, styled numbers to their values. The download is generated in the tab; no server round trip exists in the flow.

6. 6

   Feed the pipeline

   Import, diff, archive, or version it. What the receiving system gets is plain, predictable text rather than a workbook's opinions about formatting.

An .xlsx file is a ZIP archive, and you can verify this yourself: rename a copy of any workbook to .zip and open it. Inside sits a small file tree standardized by ECMA-376 — Office Open XML. A [Content_Types].xml manifest describes the parts; xl/workbook.xml lists the sheets; each worksheet is its own XML part with rows and cells; xl/sharedStrings.xml holds the text; styles.xml describes number formats, fills, and fonts.

The shared strings table is the piece worth understanding, because it explains half of what a converter does. Excel does not store the word Verdun two hundred times; it stores it once in sharedStrings.xml and points two hundred cells at index 47. Reading a sheet therefore means resolving cell references against the string table — and a converter that skips this step produces CSVs full of integers where names used to be.

Numbers keep a private life too. The cell you see as $1,284.50 is stored as 1284.5 plus a style index pointing at a currency format in styles.xml. The value and the costume are separate parts of the file, which is why format information can be preserved or discarded deliberately during conversion. This tool exports the value, and renders dates through their format so the CSV carries 2026-03-04 rather than a raw day-count — a distinction the next section makes worth its own headline.

Every formula cell in a workbook stores two things: the formula itself, and the value Excel computed the last time the file was open. In the XML they are side by side — the formula in an f element, the cached result in a v element. When Excel saves, it writes both.

A CSV has room for one of them, and the right one is almost always the value. An importer receiving =VLOOKUP(B2,Sheet3!A:D,4,0) can do nothing with it; the same importer receiving 18.40 can do everything. So this converter resolves each formula cell to its cached result — the number the author last saw on screen.

The caveat is worth saying out loud: a cached value is only as fresh as the workbook's last save. If someone edited inputs and crashed before recalculation, the cache is stale by exactly those edits. The percentages and totals you export are the ones the author believed at save time. For audit-grade exports, open the workbook in Excel, force a recalculation (Ctrl+Alt+F9), save, and then convert.

There is a rarer failure mode: a file generated by a library that writes formulas without cached values, leaving the v element empty. Excel recalculates these on open — but a converter without an engine cannot. Cells like that export blank, and the fix is the same: one open-and-save in Excel fills the cache, after which the browser conversion is complete.

Turn on the BOM option and the file begins with the bytes EF BB BF — a byte-order mark that announces UTF-8. It sounds ceremonial. It is not. It exists because Excel, faced with an unmarked file, guesses the encoding from your system's code page, and the guess is wrong often enough that non-English text arrives as mojibake: proper names becoming syllable soup in the cells of whoever receives your export.

The BOM is the one signal Excel reads reliably. With those three bytes in place, UTF-8 files with any script — Spanish accents, German umlauts, Greek, Cyrillic, Chinese — open correctly on a default installation. The cost is three bytes, invisible to every serious CSV consumer, and the occasional old tool that prints the mark as a stray character at the start of the first field. The trade is worth it whenever a human might open the file; skip it only when the consumer is a program you know hates it.

Delimiter choice rides the same regional logic. Comma is the convention English-locale systems expect; semicolon is what Excel itself writes when your locale uses a comma as the decimal separator. If your import target documents one specifically, believe the documentation. If it says nothing, comma with a BOM is the combination that survives the most trips through the most software.

A supplier sends pricing_2026.xlsx — three sheets: Summary, Line Items, and Notes. The import needs Line Items. It contains formulas for extended prices, a hidden discount column, and dates in the valid-from column. Here is the round trip.

Notice what the CSV quietly lost, on purpose: the discount percentage is no longer visible as a formula, the styling is gone, and the workbook's Summary and Notes sheets did not travel. That is correct behavior for a single-table format — the conversion is lossy in the ways a CSV is lossy and faithful in the ways an importer needs. If you need the other sheets, export them too: one CSV each, from the same screen.

Excel does not store dates. It stores day-counts — serial numbers where 1 means January 1, 1900, and 45,658 means January 1, 2026 — and uses cell formatting to dress them as dates. All date arithmetic in spreadsheets is really integer arithmetic, which is why subtracting two date cells gives you a number of days without anyone asking questions.

Now the historical wrinkle, which Microsoft has documented in its own support articles: Excel treats 1900 as a leap year, and it does so on purpose. Lotus 1-2-3, the spreadsheet that ruled before Excel, contained that bug; Excel reproduced it to keep workbooks compatible, and so February 29, 1900 — a date that never existed — occupies serial 60. Any date on or after March 1, 1900 is shifted by one day relative to the true calendar unless the software honors the same fiction.

For modern data this is trivia — anything after March 1900 lines up, and your import pipeline is not ingesting Victorian ledgers. But two habits fall out of it. First, expect any date before March 1, 1900 to be a compatibility fiction rather than history. Second, when a CSV from some other tool shows a date one day off from the workbook, the 1900 system is the usual suspect, and the fix is to export dates through their formatting rather than as raw serials — which is what this converter does.

Merged cells are the classic trap. A merged range keeps its value in the top-left cell and leaves the rest empty, so a sheet with a merged department header exports as one populated cell followed by blanks. The CSV is a faithful rendering of the data — the visual layout was the lie — but if you expected every row to carry its department, the source workbook needs unmerging first.

• Hidden sheets are listable and exportable — they contain data, so the converter treats them as real, and you decide
• Filtered-out rows export unless you tell the tool to skip them; filters are a view, not the data
• Very long sheets meet the format ceiling: 1,048,576 rows and 16,384 columns per sheet, full stop
• Cells formatted as currency or percent export as their underlying values — 12.5% becomes 0.125, which is the number the format was displaying
• Charts, images, pivot tables, and macros do not travel: a CSV is cells and nothing else, and .xlsm macro sheets export their cell data with the code left behind

The percent case deserves a flag, because it ambushes people weekly. A cell showing 12.5% stores 0.125; the percent sign is formatting. Export it and the CSV says 0.125. That is correct, and it is also the number your receiving system should store — but if the target expects 12.5, someone should multiply before the import, and it is better to know now than in the error log.

CRM and marketing-automation admins live here: their platforms import CSV, their vendors export workbooks, and the mismatch is somebody's Tuesday. Data engineers land in the same spot when a stakeholder answers a data request with a spreadsheet rather than a query result — the polite move is to convert it and move on.

Accountants convert ledger exports for tax software that insists on flat files. Researchers move instrument output and survey workbooks into statistical tools that want text. Journalists convert public-sector spreadsheets — budget files, salary schedules, procurement logs — into something grep-able and diff-able. Procurement teams convert supplier price sheets before loading them into comparison tools.

• Platform imports: CRM, marketing automation, ERP, learning management systems
• Data handoffs between teams whose tools disagree about file formats
• Public-record spreadsheets destined for analysis rather than viewing
• Backward flows: old workbooks feeding scripts and pipelines that read text
• Any file containing data too sensitive to upload to a conversion service

The shared thread is conversion under constraint — no Excel on the machine, no install permission, no time, or no willingness to send the file elsewhere. Where those constraints do not apply, any route works. Where they do, this is the page people keep bookmarked.

Three routes exist and each has a defensible lane. The honest comparison, including where ours finishes second:

If you convert the same workbook shape every Monday, write the script — twenty lines of pandas outlast any browser tab, and automation is the correct answer to repetition. If Excel is open in front of you and it is one sheet, Save As is faster than any tool including ours. The browser lane wins on the other two axes: it requires nothing installed, and it never copies the workbook anywhere — which, for files full of salaries or customer records, is the whole game.

One more consideration for the comparison shopper: web converters that process server-side outnumber the client-side ones, and the difference is invisible in the interface. The tell is in the privacy policy and, more reliably, in the Network tab of your browser's developer tools while a file converts. Ours shows no request carrying your data, because there is none to show.

Worth restating with the mechanics visible: the converter uses the browser's FileReader API to pull the .xlsx bytes into the page, unpacks the ZIP in JavaScript, resolves shared strings and cached values in memory, and builds the CSV text right there. The download you receive is generated by the tab itself. There is no upload code in the tool — not a disabled one, an absent one.

The audit is the same thirty-second test we recommend for every tool on this site: open developer tools, load a workbook, and watch the Network panel. Scripts and assets load; nothing the size of your file moves. Then go offline and convert another sheet — it works, because it never needed the network in the first place.

No account, no file history, no retention policy. The tab holds your workbook only as long as it is open. For anyone whose employer has opinions about where data may travel — and employers are right about this one — the entire compliance answer fits in a sentence: the file is processed on the employee's device and is not transmitted anywhere.

The reverse lane is the CSV to XLSX Converter, which builds real workbooks from text exports with typed columns and delimiter sniffing — the tool to hand someone whose Excel keeps eating their files. For legacy spreadsheets, the XLS to CSV Converter unpacks the old binary format the same way this page unpacks the modern one.

And when the destination is code rather than a file transfer, the XLSX to JSON Converter turns the same sheets into arrays of objects with header mapping — the natural next step once your spreadsheet stops being paperwork and starts being a data source.