Markdown vs JSON vs HTML as LLM Input Formats for Web-Extracted Data

For LLM-ready structured data extraction from web pages, the best input format depends on the task. Markdown is the default for reading and retrieval, JSON fits exact fields and machine-consumed output, and HTML belongs where the markup itself contains the evidence. The choice depends on token cost, structural fidelity, and reasoning accuracy, so every page need not go through the same funnel.

Why the format you use to feed web-extracted data to an LLM is a performance variable, not a style choice

An LLM reads a web page as a raw token stream, including the wrappers around the content it needs. Every angle bracket, repeated key name, and piece of boilerplate competes with the information the model needs to reason over. The browser tidies the room for its visitor. The model gets the packing materials too.

That difference makes serialization an engineering choice that affects token cost, reasoning reliability, and chunking integrity. Token cost sets how much the pipeline pays to process its input. Reasoning reliability depends on whether the model can read the links between parts of that input, while chunking integrity depends on whether those links hold when the input is split into pieces for retrieval. A format can improve one and weaken another. Removing structure may shrink a payload but also erase the boundary between two ideas or the relationship between a field and its value.

The same information can thus cost more or less and lead to different answers depending on how it is packaged. At scale, those differences are large enough to change what a pipeline costs and how often it gets answers right, as well as make a prompt look tidier. Cheap input is not automatically reliable input. Some parts of the structure help the model perform its task, while others simply accompany the bill.

How much the token gap between formats actually costs in practice

HTML makes its overhead easy to see. Paired elements add opening and closing tags, often accompanied by class, id, style, and data-* attributes. Nested elements repeat that wrapping around content that may need only a heading or paragraph boundary for a reading task. The model still processes the wrapping. FormatArc’s Markdown-vs-HTML benchmark measured HTML consuming more than three times as many tokens as Markdown for identical content on a sample page.

That comparison establishes the scale of the opportunity. When the task needs the page’s words, a large part of the HTML payload can be overhead. The cost of paying for it once may be easy to miss. Paying for it across every request turns an untidy representation into a recurring cost.

JSON introduces a different kind of bulk through repeated field names, punctuation, and, when pretty-printed, formatting whitespace. A 2025 empirical analysis of nested data formats found Markdown used 34–38% fewer tokens than JSON. For tabular numeric data, a Markdown pipe table or CSV can encode rows more densely than JSON because it does not repeat the same keys throughout the records. Pretty-printing adds more overhead while the values stay the same.

These comparisons measure input tokens. Their practical significance is that the gap repeats with the workload. A high-volume pipeline does not receive the saving once and move on. Its costs change with the format, so matching the format to the task deserves care beyond taking the first export option chosen.

Why Markdown has become the default format for reading and RAG tasks

Markdown is the strongest baseline when the model must read prose, summarize it, answer questions about it, or retrieve passages for grounding. It combines compact input with recognizable structure. Headings, lists, code fences, and tables express how the content fits together without reproducing the page’s presentation machinery. For these tasks, that is the useful middle ground. Plain text can discard relationships, while HTML often preserves much more than the task needs.

Training-data alignment reinforces that fit. Capable LLMs were trained on large repositories of technical documentation, GitHub READMEs, and forum content in which Markdown is common. Heading levels and code fences therefore serve as familiar structural signals. The format gives the model a readable outline. It does not need paired tags and attribute slots to distinguish a section title from the paragraph below it.

That outline also gives a RAG pipeline sensible places to split a document. Header-based chunking at H1, H2, and H3 boundaries follows how the document is laid out, helping keep ideas together by splitting where the text marks a break. Those coherent chunks support meaningful embeddings and retrieval. A split in the middle of a sentence does neither any favors. The heading is more than decoration when it tells the retrieval system where one topic ends and another begins.

A pricing table flattened into raw text can lose the relationship between its columns, leaving the model to infer which value belongs where. Markdown’s pipe-table form keeps the grid explicit with little markup. The separators earn their place in the input because they preserve meaning.

For a pipeline built around reading, the practical recommendation is therefore to convert raw HTML to clean Markdown before ingestion. Boilerplate should be stripped while headings, tables, and links remain. This gives summarization, question answering, grounding, and citation tasks the content and its useful organization without making the model sift through the page’s scaffolding.

Where JSON is the correct choice and why using it as general-purpose input is a mistake

JSON becomes the right choice when exact field identity is part of the job. If a prompt asks for each product’s sku, price, and in_stock, those keys provide an explicit contract between the data and the task. The model can address a field by name. Here, repetition has a purpose. A key that looks wasteful in a reading task may remove ambiguity in an extraction task.

That precision is essential when extracted fields must go directly into a database or downstream system. A title, price, author, date, or SKU needs a consistent place in the output. The consumer sets the requirement. A parser is not impressed by elegant sentences, and a downstream function expecting a typed object cannot treat schema adherence as a stylistic preference.

Tool inputs and outputs are consequently a natural home for JSON, as is RAG chunk metadata. Fields such as url, title, headings, and chunk_id need consistency across records so that retrieval can use them reliably. This is a different job from presenting the chunk’s prose to the model. The metadata identifies and organizes the content, while the content supplies what the model must read.

Putting long texts for reading in JSON blurs that distinction. Repeated keys and quoting increase input overhead without automatically improving comprehension. Where a pipeline also asks the model to reproduce JSON, trailing commas and schema drift become additional concerns. Strictness is worth its cost when a machine consumer needs it.

In the same pipeline, JSON can hold extracted fields and structured attributes while Markdown holds the prose that goes with them. Input and output also need not share a format. A model can read content suited to reading and return fields suited to parsing, with each side shaped for the work it must do.

The narrow but real cases where HTML is the right input format

HTML earns its place when the required evidence lives in markup. An accessibility audit, for example, may need aria-label, role, and tabindex attributes. Turning the page into ordinary Markdown strips away the very attributes the audit needs to check. The extra tokens are then evidence. A leaner representation that loses those attributes has optimized away the task.

Structured product metadata creates another exception. Attributes such as itemprop and itemtype, including schema.org microdata, encode typed information about price, availability, and brand within the HTML. A task auditing or extracting that markup needs access to it. Reading the visible product description is not an equivalent substitute.

The HTML head presents the same boundary for Open Graph and meta tags. Fields such as og:title, og:description, og:image, and canonical URLs are outside what a body-only Markdown conversion preserves. Their absence is not a cosmetic loss. If the task asks about them, the input must retain them.

The practical test is whether the job can be completed from the visible rendered text. For prose reading that passes this test, Markdown is the appropriate input. When the question instead depends on attributes or head metadata, HTML preserves the signal that conversion would remove.

Why accuracy does not reliably increase with token count, and what that means for format choice

A compact format can preserve all the values yet make their relationships harder for a particular model to use. On the other hand, extra structure can help the model reason well enough to be worth its input cost. There is no dependable rule that more tokens buy more accuracy. The smallest payload can also fall short of the best answer.

Tabular records make that distinction concrete. A benchmark of eleven formats found Markdown-KV, which holds records as Markdown key-value pairs, had the highest accuracy, beating CSV even though it used far more tokens. Standard Markdown-Table came seventh even though it was among the formats that used the fewest tokens. The two Markdown representations did not behave alike. Grouping them under a single format label would conceal the difference that the decision needs to capture.

This finding qualifies, rather than overturns, the case for Markdown in reading and RAG. Prose retrieval and reasoning over large record sets ask different things of structure. A compact pipe table can retain a readable grid without being the representation that delivers the best reasoning accuracy across records. The relevant unit of comparison is the task and representation together.

Nested data adds a model-specific qualification. Markdown was the most token-efficient format across the tested models, using fewer tokens than JSON, but efficiency did not settle the accuracy ranking. Llama 3.2 3B Instruct showed little format sensitivity on the nested-data tasks, with formats performing similarly. A format that does better elsewhere may offer no such gain for that model. The result depends partly on who is doing the reading.

For structured and nested data, the lesson is to test candidate formats against the specific model and task in the pipeline. The comparison should consider token usage and reasoning accuracy together. A cheaper representation is useful only in relation to the quality the task requires.

How should you choose Markdown, JSON, or HTML for your LLM pipeline?

The decision begins with two questions, namely what the model will do with the data and what will consume its output. These separate reading requirements from schema requirements. They also expose cases where one payload needs more than one representation. Choosing a single format for an entire pipeline is often an unnecessary constraint. The page, the model, and the downstream parser do not all need the same view.

For summarization, question answering, document grounding, or RAG over prose, the recommended path is to convert raw HTML into clean Markdown before ingestion. That conversion should remove boilerplate and preserve headings, tables, and links so the reading and chunking steps retain useful structure. Human-read output also favors Markdown.

JSON is the right choice for defined-schema extraction, exact field access, and tool calling. The downstream parser, database, or function determines the required contract. When formatting is not needed, minified JSON reduces overhead compared with pretty-printed JSON. Prose can stay in Markdown while JSON holds the fields that need predictable names and types.

HTML should be kept when the task needs accessibility attributes, product microdata, Open Graph tags, or other markup that the rendered text leaves out. For structured or nested data where accuracy outweighs token cost, YAML or Markdown-KV are also worth testing against JSON. Empirical results favor YAML for nested structures particularly outside the Llama family, but the target model remains the deciding test. A benchmark provides guidance.

For an extraction API, the useful criterion is whether its output matches these needs without another cleaning stage. That means clean Markdown with useful document structure, JSON fields suited to the downstream schema, and retained HTML where attribute-level evidence is required. The practical hybrid is to request Markdown for content and JSON for metadata in the same API call.