Excel to Markdown: Turning Spreadsheets Into Tables an LLM Can Reason About
Ask a language model a question about a spreadsheet you've pasted in raw and you'll often get an answer that's confidently wrong about which column is which. That's not the model being stupid. A spreadsheet is a coordinate grid — cell B7 holds a number, and nothing in the file says that number belongs to the "Q3 Revenue" column. Humans infer that from position. Paste the values as a jumble and the model has to infer it too, from much worse evidence.
Converting Excel to Markdown fixes this by producing a real pipe table: a header row, a separator, then aligned data rows. That format is unambiguous about column membership, and models handle it well because Markdown tables are everywhere in their training data. If you want to convert an Excel file to a Markdown table online, drop an .xlsx or .xls into the box above. Free, no account, 50 MB ceiling, nothing retained.
What the Output Looks Like
A workbook is a collection of sheets, and each sheet becomes its own section in the output, labelled with the sheet's tab name. That labelling matters more than it sounds — "Assumptions", "2024 Actuals", and "Do Not Edit" carry real meaning about how to treat the numbers underneath them, and a model that can see the tab name will use it.
Within each sheet, the first populated row is treated as the header, followed by the alignment separator row, then every data row rendered with pipe delimiters. The result reads like this in structure: column names across the top, values lined up beneath them, one record per line. Once your data is in that shape, you can ask column-wise questions — "which regions grew more than 10 percent", "find rows where status is blocked and owner is empty" — and the model has enough to actually check rather than guess.
Formulas, Values, and What You're Really Getting
This one surprises people. An .xlsx stores two things for a formula cell: the formula itself
(=SUMIF(D:D,"North",F:F)) and the last computed result, cached from when Excel last
recalculated. Conversion reads the cached value. You get 184,500, not the SUMIF.
That's the right default — the number is what you want to reason about — but it has two consequences worth holding onto. First, the model can see what the answer is but not how it was derived, so it can't audit your logic or spot a broken range. Second, if a file was generated by a script or an export tool that wrote formulas without ever opening Excel, the cached values may be missing or stale, and those cells can come through empty or wrong. Open the file, let it recalculate, save, then convert. Takes ten seconds and rules out a whole category of confusion.
The Things That Break Tables
Markdown tables are rigid: every row must have the same number of columns. Spreadsheets are not rigid at all. That mismatch is where nearly every messy conversion comes from.
- Merged cells. A merged cell stores its content in the top-left cell of the merge range and leaves the rest genuinely empty. A title merged across A1:F1 becomes one value followed by five blanks, and if that's your first row it gets read as your header. Merged category labels down the side of a report produce a value on the first row of the group and nothing on the rest.
- Multi-row headers. The classic "2024" spanning three columns above "Q1 / Q2 / Q3" layout has no representation in a Markdown table. One of those rows becomes the header and the other becomes a data row full of quarter names.
- Blank spacer rows and columns. Visual breathing room in Excel becomes empty rows and unnamed columns in the output, which quietly consume tokens and dilute the table.
- Data not starting at A1. A logo in the corner, a note in row 2, and the actual table beginning at row 6 — the converter has no way to know rows 1 through 5 were decoration.
- Multiple tables on one sheet. Three separate blocks side by side become one very wide, mostly empty grid.
The fix for all of these is the same and it's boring: before converting, make a copy of the sheet with one header row at the top, one table per sheet, no merges, no spacer rows. Two minutes of tidying is worth more than any clever prompt afterwards.
Dates, Numbers, and Why Your Cell Says 45231
Excel does not store dates as dates. It stores a serial number counting days from an epoch, and the thing
you see — 15/03/2024, or Mar-24, or Friday — is a display format layered on top. Conversion reads the
underlying value, so date columns can come through as bare integers if the formatting doesn't carry over.
If dates matter to your analysis, force them into unambiguous text before you convert: add a column with
=TEXT(A2,"yyyy-mm-dd") and use that. ISO format also removes the British-versus-American
day/month ambiguity that quietly ruins date reasoning.
Number formatting works the same way. A cell displaying £1,250.00 or 12.5% holds 1250 and 0.125. Percentages arriving as decimals is the specific one that trips people up — a model told to find values above 10 will find nothing in a column of 0.125s. Where the unit isn't obvious, put it in the column header rather than relying on the cell format: "Growth (%)" or "Revenue (GBP)".
Width, Tokens, and Knowing When to Stop
Markdown tables cost more tokens than the same data in flat form, because every row pays for its delimiters. Roughly speaking, each column adds a pipe and some padding to every single row — so a 40-column sheet with 5,000 rows spends a meaningful chunk of its budget on punctuation before a single value is read. Wide sheets are where xlsx to Markdown conversion goes from useful to unaffordable.
Two habits keep this in check. Delete the columns you don't need before converting — most exports carry twenty fields where your question touches four. And watch the token counter under the output; it tells you immediately whether the result fits your model's context window or whether you should be filtering first. If the sheet is enormous and the question doesn't require column alignment, Excel to plain text is the cheaper route, and the toggle at the top of this page will carry your file across to it.
.xlsx, .xls, and CSV
Modern .xlsx files are ZIP archives of XML — well-structured and reliable to parse. Legacy .xls is a binary format from the pre-2007 era, and it's still handled here, but it's worth knowing that it caps out at 65,536 rows and 256 columns, and that files exported from old accounting or ERP systems sometimes lean on quirks that don't survive perfectly. If you have the choice, resave as .xlsx first.
If your data started as a CSV, skip Excel entirely — go to CSV to Markdown instead. One less format hop, no risk of Excel helpfully converting your product codes into dates or stripping the leading zeros off postcodes on import.
Frequently Asked Questions
How do I turn an Excel spreadsheet into a Markdown table?
Upload the .xlsx or .xls above and each sheet comes back as a pipe table you can paste into a README, a wiki, a pull request, or a model prompt. Free, 50 MB per file, no account. The header row stays a header row, so alignment survives the trip.
Does it keep the header row and column alignment?
Yes, and that is the whole reason to choose Markdown over flat text here. A pipe table preserves which value sits under which heading, so an assistant reading it can answer "what was the March figure for the EMEA region" correctly. Flatten the same sheet to text and that question becomes unanswerable.
What happens to merged cells and multi-row headers?
They flatten awkwardly. Markdown pipe tables have exactly one header row and no concept of a cell spanning two columns, so a report with a merged "Q1 2026" banner above three sub-columns loses the banner. Sheets built as clean rectangular data convert perfectly; sheets built to look good when printed usually need a manual fix.
Will a very wide spreadsheet still be readable?
Readable to a machine, unpleasant for a human. A forty-column sheet becomes a pipe table with forty columns and lines running to several thousand characters. Models parse it fine. If a person has to read it, transpose the sheet in Excel first or cut it down to the columns that matter before converting.
Do charts and pivot tables convert?
No. Charts are drawing objects with no text body, and a pivot table's output converts as the cells it currently displays rather than as a live pivot. What you get is the underlying grid of values, which is usually what you actually wanted to hand to a model anyway.
The Rest of the Toolkit
Spreadsheets usually arrive attached to something else. File2Txt handles every supported format from a single page, and the neighbours worth knowing are PDF to Markdown for financial reports, PowerPoint to Markdown for the deck the numbers ended up in, and JSON to Markdown when the same data came out of an API instead.
On the code side there's the GitHub repository to text converter and a local folder converter, plus Web2Txt for web pages. The guide to preparing files for LLMs goes wider than spreadsheets if you want the overview.
Repo2Txt is built and maintained by v12hero, an independent developer building privacy-first native and web apps.