Markdown vs. JSON vs. Raw Text: How to Optimize Token Usage and Model Performance with Structured Parsing
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.
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.
Raw text
Markdown
JSON (verbose)
JSON (compact schema)
Design JSON for token efficiency
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.
{ "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.”
Parses first try
Needs a retry
Manual fix
How Parser's output formats map to this
Parser returns the fields you define as structured data, in the formats every plan lists: JSON, Excel and CSV. Mapped to the guide above:
- JSON for system-to-system automation into ERPs, databases, and BI, through the REST API or a webhook.
- Excel or CSV for the human review layer, where a person checks the values in a spreadsheet.
Markdown and raw text are not on that list: they are formats you choose for the text you give a model in a pipeline of your own.
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.
What documents benefit most from intelligent document processing?
High-volume, semi-structured documents — invoices, receipts, contracts, and transport documents — where the layout varies but the fields you need are consistent. Parser's solution pages cover invoices, contracts and receipts.
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.