Markdown vs Plain Text vs JSON: Which Format for LLM Context?
The same document can reach a model as flat text, as Markdown, or as structured JSON. The choice changes token cost, how well structure survives, and what the model can reliably do with it.
LLM workflows · · 3 min read
Plain text
Plain text is the smallest and most portable option. Every token is content: no syntax characters, no keys, no punctuation spent on structure. When you are close to a context limit, it fits the most words into the fewest tokens.
What it costs you is every distinction the document made. A heading and a body sentence become the same thing — a line of text. Nested list depth disappears. Table columns become a stream of values in reading order. Any question whose answer depends on where something sat in the hierarchy becomes guesswork.
Use it when structure genuinely does not matter: keyword search indexing, word counts, diffing revisions, or a document that was flat prose to begin with. Our PDF to Text converter also strips repeating headers and footers, which removes a meaningful amount of noise from paginated documents before they ever reach a model.
Markdown
Markdown is the middle option and the right default for most prompting. It marks hierarchy with a handful of characters that models parse natively, having been trained on enormous quantities of it. The overhead over plain text is small — a few characters per structural element — and what you buy is an explicit outline.
The practical effect shows up in tasks that depend on document shape. "Summarise each section" works when sections are marked and degrades into guesswork when they are not. "What does the termination clause say" is far more reliable when the model can see a heading called Termination than when it must locate the clause by topic drift alone.
Markdown also degrades gracefully. If heading detection misses a level, you still have readable prose — not a parse error. That tolerance matters when input quality varies across a corpus you do not control. Convert with the PDF to Markdown converter, or from Word with DOCX to Markdown.
JSON
JSON is the most expensive per unit of content and the only option a program can reason about reliably. Keys, braces and quotes all consume tokens, and a naive JSON dump of a long document can cost noticeably more than the same content as Markdown.
You pay that for addressability. In our JSON output, every line carries a type, a page number, a font size and a position. That lets code filter headings to build an outline, group lines into sections, attach page-level citations, or chunk on structure — all before a model is involved at all.
The important shift is that JSON is usually not what you send to the model. It is what your pipeline consumes in order to decide what to send. Parse to JSON, chunk and filter programmatically, then render the selected pieces as Markdown for the prompt. You get structural precision where you need it and token efficiency where the model actually reads.
Choosing, in one pass
A person or a chat window will read it: Markdown.
A program will process it: JSON, then render the parts you need as Markdown before prompting.
You are against a hard context limit and structure is genuinely irrelevant: plain text.
You need citations back to specific pages: JSON, because nothing else carries page numbers through.
The document is a scan: none of the above until OCR has run — there is no text layer for any of these tools to read.
A note on token cost
It is tempting to optimise format choice around token count. In practice the differences between plain text and Markdown are small — single-digit percentages on typical documents — while the difference in answer quality on structure-dependent tasks is large.
JSON is the case where cost is worth watching, because the overhead is real and scales with line count rather than word count. A document of many short lines can be dramatically more expensive as JSON than as prose. That is another argument for treating JSON as a pipeline format rather than a prompt format.