Formats are usually chosen for what reads them downstream. When the reader is a language model with a fixed context window and a per-token bill, the choice becomes a cost decision — and the default choice, JSON, is close to the most expensive option available. The saving from picking differently is not marginal; on tabular data it is routinely more than half.
The short version
For tabular data going in: CSV is cheapest, markdown tables are close and more readable, JSON costs roughly two to three times either.
For structured data coming out: JSON regardless. It is the only one with real schema enforcement, and correctness beats economy on output.
The overhead is almost entirely repeated keys, so the saving scales with row count and vanishes on a single record.
Where the cost actually hides
Take three records and write them four ways. The data is identical throughout.
The JSON version spends a large fraction of its tokens on three words the model already knew after the first row. That is the entire phenomenon. Everything else — quotes, braces, commas — is real but secondary.
| Format | Keys sent | Relative cost | Best for |
|---|---|---|---|
| CSV | Once | 1.0x | Flat tables, many rows |
| Markdown table | Once | ~1.2x | Tables the model must reason over |
| YAML | Every record | ~2.0x | Config, nested structures |
| JSON | Every record | ~2.5x | Output, nesting, tooling |
| JSON (pretty) | Every record | ~3.0x | Nothing, when sending to a model |
⚠️ These ratios are approximate, and yours will differ
The multipliers depend on your field-name lengths and value lengths. Long keys with short values — customer_account_identifier: 4471 — push JSON's overhead far higher. Short keys with long text values compress the difference to almost nothing.
The rule that generalises is structural, not numerical: cost scales with how many times you repeat the schema. Measure your own data with your model's tokeniser before assuming a number.
Pretty-printing is a pure loss
Indentation and newlines exist for human readers. Send them to a model and you pay for whitespace that conveys nothing the structure did not already carry.
Models parse minified JSON without difficulty. If you are sending JSON at all, minify it — it is the one change here with no trade-off whatsoever. Our JSON formatter minifies in the browser, and the same tool will pretty-print it back when a human needs to read it.
Where CSV stops being the answer
CSV wins on flat, rectangular data and degrades badly outside it. Push nested structures through it and you rebuild JSON inside a cell, at worse cost than sending JSON.
The decision is about shape, not preference:
- Flat and rectangular, every row the same fields → CSV.
- Nested or irregular, optional fields, varying depth → JSON.
- Mostly flat with one nested field → flatten it into columns (
address_city,address_primary) and stay in CSV. - Configuration a human also edits → YAML, where readability is the actual requirement.
The trade nobody mentions
Token efficiency is not free. The formats that repeat keys repeat them for a reason: they put the label next to the value.
🚨 Wide CSVs invite column drift
In a CSV with twenty columns, the header is a long way from row 400. The model must hold the column order in mind across the whole table to know that the seventh value is status and not region. It mostly manages. On wide tables of similar-looking numbers, it sometimes does not.
JSON's repetition is the thing making it expensive and the thing making it robust — every value arrives labelled. If your extraction accuracy drops after switching to CSV, this is why, and the fix is fewer columns rather than more tokens.
Practical mitigations that keep most of the saving:
- Send only the columns you need. The largest saving available is not a format change — it is not sending data the task does not use.
- Put important columns first, where alignment errors are least likely.
- Prefer markdown tables above about ten columns. The pipes give the model visible column boundaries, which is worth the small premium over CSV.
- Restate the header periodically in very long tables — every hundred rows or so — so the labels are never far away.
Input and output are different questions
Everything above concerns data going into the model. Coming out, the calculus inverts completely.
| Input | Output | |
|---|---|---|
| What matters | Token cost | Parse reliability |
| Volume | Often huge | Usually small |
| Schema enforcement | Not applicable | Available for JSON |
| Recommendation | CSV or markdown | JSON, always |
Ask for CSV output and you inherit every ambiguity CSV has — commas inside values, inconsistent quoting, no way to signal a missing field distinctly from an empty one — with no schema to validate against. Ask for JSON and you can use constrained decoding to make invalid output impossible rather than merely unlikely. Output volume is small; the token saving would be trivial and the reliability cost is not.
One more thing: numbers tokenise badly
Format choice is not the only lever. Numeric precision you do not need is pure waste, because long numbers fragment into several tokens each.
Round to the precision the task requires, and strip identifiers the model will never reference. A UUID per row costs real tokens to communicate something the model cannot use.
Converting between CSV and JSON?
Convert, minify and validate CSV and JSON entirely in your browser — nothing is uploaded to a server.
Open JSON to CSV →Summary
- Repeated keys are the cost. JSON sends your schema once per row; CSV sends it once.
- CSV is cheapest for flat tables, markdown tables close behind and easier for the model to align.
- Minify any JSON you send. Pretty-printing is a pure loss to a model.
- Nesting kills the CSV advantage — escaped JSON in a cell is worse than JSON.
- Compact formats can cost accuracy on wide tables, because labels sit far from values.
- The biggest saving is sending fewer columns, not changing format.
- Output should be JSON regardless — schema enforcement beats token economy.
- Round your numbers. Unused precision fragments into tokens you pay for.
Frequently Asked Questions
Which data format uses the fewest tokens for an LLM?
For tabular data, CSV is consistently the cheapest, because field names appear once in the header rather than being repeated on every record. Markdown tables are slightly more expensive but more readable to the model. JSON arrays of objects are the most expensive by a wide margin, since every key is repeated for every row.
Why is JSON so expensive in tokens?
Repeated keys. In an array of objects, every field name is transmitted again for every record, so a 500-row export sends each key 500 times. On top of that, the structural punctuation — braces, brackets, quotes around every key and string, and commas — adds tokens that carry no data.
Should I use CSV instead of JSON to save tokens?
For flat tabular data going into a model, usually yes. For nested or irregular data, no — CSV cannot express nesting without ugly workarounds that cost more than they save. And for model output, ask for JSON regardless, because it is the format that structured output and schema validation actually support.
Does saving tokens hurt accuracy?
It can. Very compact formats put more distance between a value and the label explaining it, and models make more column-alignment mistakes on wide CSVs than on labelled formats. The saving is real, but on data with many similar numeric columns it is worth checking that accuracy holds.
Is YAML more token-efficient than JSON?
Modestly, for configuration and nested structures, because it drops braces, brackets and most quotes. For repeated records it is not much better than JSON, since it still repeats keys on every item, and its indentation consumes tokens too.