Markdown vs JSON vs Raw Text for LLMs: Which Format Uses Fewer Tokens?

Guilherme Michels — Tue, 27 Oct 2026 17:09:28 +0000

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.

DEV Community: Guilherme Michels