# Markdown vs. JSON vs. Raw Text: How to Optimize Token Usage and Model Performance with Structured Parsing

> Wrong format, wasted tokens: markdown vs JSON vs raw text for LLM prompts and outputs, compared on token count, parse reliability and accuracy.

- Source: https://parserai.co/blog/markdown-vs-json-vs-raw-text-how-to-optimize-token-usage-and-model-performance-with-structured-parsing
- Published: 2026-02-18

---
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.

_Illustrative token count to represent the same one-page invoice in each format._

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 the example above, the same invoice 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.

invoice.json — an example result pinned to a schema

```
{
  "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.”

_Illustrative outcome distribution when output is pinned to a validated schema._

## 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.

Parser

## See it on your own documents.

In the demo we process your documents live — no slides, no fluff.

[Book a demo](https://parserai.co/demo)