Every prompt you send to a language model has a price and a failure mode. The format you feed in — and the format you ask the model to return — quietly decides how much you pay per document and how often the output breaks your automation downstream.
Why token efficiency is more than "saving money"
Tokens are the unit LLMs read and bill in. When you waste them, you don't just pay more — you push closer to context limits, slow every response down, and give the model more room to drift off the structure you actually need. On a workflow that processes thousands of documents a month, the format decision compounds into real cost and real accuracy.
In short:
- 3 formats compared: raw text, Markdown, JSON
- 4 habits that inflate a token count: repeated keys, nesting, long names, whitespace
- 1 schema to validate every result against
Quick definitions: raw text, Markdown, and JSON
Raw text is the plain, unstructured dump of a document — everything the OCR or parser saw, in reading order, with no markup. It's the cheapest to produce and the hardest to trust: there's no signal about what a value means.
Markdown keeps a light layer of structure — headings, lists, tables — that humans read comfortably and models reason over well. It's the sweet spot for anything a person still reviews.
JSON is machine-native. Every value has a named field, so downstream systems can consume it without guessing. It's the format you want the moment a document feeds an ERP, a database, or a payment run — as long as you design the schema deliberately.
The big trade-off: human readability vs. machine reliability
There is no single "best" format — there's the right format for where the output is going. Raw text and Markdown are easy for people; JSON is reliable for machines. Push structure too early and you fight the model; push it too late and you hand a human a wall of text to reconcile by hand.
Token usage: what increases or reduces the count
Token-heavy patterns are the usual culprits: repeated keys, deeply nested objects, verbose field names, and pretty-printing with lots of whitespace. Token-efficient patterns do the opposite — short but clear keys, flat structures where possible, and a stable schema the model can lean on instead of re-describing.
Design JSON for token efficiency. A compact, well-named schema can cut tokens versus a naïve verbose dump without losing a single field you care about. In an illustrative one-page invoice, the same data takes 1,610 tokens as verbose JSON and 980 as a compact schema.
When to use each format (practical guide)
| Format | Best for | Watch out for |
|---|---|---|
| Raw text | Early exploration, simple Q&A, quick summaries | No field-level meaning; hard to validate |
| Markdown | Human review layers, auditable outputs, semi-structured reasoning | Tables still need parsing before a system can use them |
| JSON | Automation, integrations, reliable downstream parsing | Verbose schemas burn tokens; drift breaks consumers |
The missing link: why structured parsing beats "prompt-only" extraction
Asking a model to "return the fields as JSON" in a free-form prompt works in a demo and fails in production. The schema drifts, a field goes missing, a number comes back as a string, and the automation that trusted it silently breaks. Structured parsing pins the output to a defined schema and validates every result against it — so what reaches your system is predictable, not hopeful.
An example result pinned to a schema (invoice.json):
{
"supplier": "ACME Components Ltd.",
"invoice_number": "INV-2026-00814",
"issue_date": "2026-02-11",
"due_date": "2026-03-12",
"currency": "USD",
"line_items": 3,
"subtotal": 4820.00,
"tax": 385.60,
"total": 5205.60
}
Because the shape is fixed, you can validate totals, normalize dates, and reject anything that doesn't fit — automatically — instead of trusting that "the model usually gets it right."
Best practices for prompts and outputs
- Keep schemas stable. A consistent schema is easier for the model and for every consumer downstream.
- Normalize and deduplicate. Standardize dates, currencies, and identifiers at extraction time.
- Prefer structured extraction over "creative" generation. You want fidelity, not prose.
- Validate totals and formats automatically. Let the schema catch what a human would miss.
Common questions
What format is best for LLM input: Markdown, JSON, or raw text?
For most extraction workflows, Markdown is the best input because it preserves structure the model can reason over while staying token-efficient. For output, JSON wins whenever the result feeds another system.
Does JSON always use more tokens than Markdown?
No. Verbose, pretty-printed JSON does — but a compact, well-designed schema can be comparable to or leaner than Markdown while remaining fully machine-parseable.
Why does structured parsing improve model performance?
A fixed schema removes ambiguity. The model spends its effort filling known fields instead of inventing structure, which reduces drift, retries, and manual fixes.
Putting it all together
Use raw text to explore, Markdown to review, and JSON to automate — and pin that JSON to a validated schema so it stays reliable at volume. The format isn't a cosmetic choice; it's the lever that controls your token bill and your automation's failure rate at the same time.
Originally published on the Parser blog. I work on Parser, which extracts the fields you define from invoices, receipts, bank statements and contracts as JSON, Excel or CSV. There's a free plan if you want to try it on your own documents.
Top comments (3)
Ran this on a single eight-line invoice using the provider's own counter rather than a local estimate, two runs per shape and identical both times — tokenization is deterministic, unlike sampling.
Raw text came out at 229 tokens, the Markdown table at 264, and minified JSON with short keys at 260. So compact JSON and Markdown are effectively tied, 4 tokens apart, and both sit about 15% above raw text: that 35-token gap over raw is what the markup buys you.
Then I added each of your four habits to the compact render one at a time, so the cost could be attributed rather than guessed at. Pretty-printing alone cost +155 tokens, long descriptive field names +66, one extra nesting level per line item +47. All four together reached 481, which is 1.85x the compact version — the same neighbourhood as your 1,610 vs 980, which is 1.64x.
The part I would add to the post: whitespace is 70% of the entire JSON penalty, 2.3x the cost of the long field names and 3.3x the cost of the nesting. So the first fix is the separator, not the schema. Dropping the indent reclaimed more tokens than renaming every key did, and unlike a schema change it cannot break a consumer.
One caveat on the numbers: they belong to one tokenizer. Absolute counts move between tokenizers, while the ratios travel better.
Thanks for actually measuring this. That's a great breakdown.
Agreed on whitespace being the first fix: dropping the indent is the cheapest win and, as you said, it can't break a consumer the way a schema change can. Our 1,610 vs 980 example was illustrative, so it's good to see the ratio hold up on a real tokenizer.
Your raw-vs-markup numbers are a useful reminder too: structure isn't free (~15% over raw text in your test), it's a cost you pay for reliability downstream. Mind if we reference your measurements if we update the original post?
Yes, go ahead — no permission needed. I would rather you had the exact conditions they hold under, so they survive review.
Everything came from one tokenizer: the provider's own counter, on one eight-line invoice, with the same data in every arm and a 1-character baseline subtracted. The wrapper alone cost 31 tokens, which is why I subtracted it rather than reporting the raw call.
What travels is the ratios, not the absolute counts. So if you update the post, I would quote "compact JSON and a Markdown table came out 4 tokens apart, both about 15% above raw text, and pretty-printing alone accounted for roughly 70% of the whole JSON penalty" — and label the absolute numbers as one tokenizer's reading. In a different tokenizer the 229 and the 260 will move; the ordering and the 70% share should not.
Being explicit that your 1,610 vs 980 was illustrative is the right call, and it is also why the ratio mattering is the useful part: 1.64x intended, 1.85x measured on the four habits combined, so the shape of the claim held even though the numbers were never from a run. Happy to paste the arm definitions and the counting function if that helps whoever re-checks it.