From HTML Tables to TOON for LLM Extraction

The best format to feed scraped HTML tables to an LLM is TOON. It preserves the tabular structure that peer research shows boosts LLM accuracy by over 40%, strips the tag and attribute noise that inflates HTML, and avoids the alignment-character overhead that makes markdown tables the most token-expensive format of all.

Why HTML Tables Are Noisy for LLMs

A raw scraped HTML table carries substantial structural baggage: <table>, <thead>, <tbody>, <tr>, <th>, and <td> tags wrap every cell, often alongside class, style, colspan, and other attributes that mean nothing to an LLM trying to extract a product price or a benchmark result. Even a compact five-column, ten-row table can balloon to several hundred tokens of tag syntax before you reach a single data value.

The common developer reflex is to convert the HTML table to a markdown table or to JSON. Both are improvements over raw HTML, but neither is optimal. JSON repeats every column name on every row. Markdown tables add visual alignment glyphs — pipes and dashed separator rows — that exist solely for human readability and contribute nothing to model comprehension.

TOON was designed for exactly this scenario: a uniform array of objects where the schema is consistent across rows. It declares the column names once in a header line and lists row values in CSV-style order beneath it, preserving the tabular structure that benefits LLM attention while eliminating all redundant syntax.

Do Tabular Structures Genuinely Help LLMs?

The evidence for keeping your data in a table-like structure when querying an LLM is stronger than intuition alone. The arXiv paper "Talking with Tables for Better LLM Factual Data Interactions" (2412.17189, updated January 2026) tested tabular structures against text blended with semi-structured formats such as JSON and knowledge graphs. The result: tabular structures yielded a 40.29% average performance gain alongside better robustness and token efficiency. Attention-weight analysis revealed why — tables help LLMs attend to relevant information more directly, rather than extracting it from narrative prose or navigating nested object trees.

The TOON format is built on this same principle. Its products[n]{field1,field2}: header gives the model an explicit schema and row count to validate against, and the plain-value rows beneath it are exactly the tabular layout the attention analysis points toward. This is not a coincidence: TOON's design was informed by how LLMs tokenize and attend to data.

Why Not Just Convert HTML Tables to Markdown?

Markdown is generally 15–20% fewer tokens than JSON, and some plain-markdown benchmarks reach 34–38% savings. Those numbers look attractive. The problem is that markdown tables specifically can be the most expensive format of all, according to developer benchmarks on the OpenAI developer forum and independent format comparisons.

The culprit is the separator row. A markdown table between the header and data rows requires a line of dashes and pipes for each column — something like | --- | --- | --- | — plus a leading and trailing pipe on every data row. On a ten-column table those alignment tokens are paid on every single row, turning what should be a compact representation into one of the most verbose options available.

TOON keeps the tabular shape the LLM benefits from, without paying the alignment tax. On flat uniform tables, the official toonformat.dev benchmarks measured 58.8% fewer tokens than JSON (67,778 vs 164,452 tokens) with 99.6% field retrieval accuracy. The combination of maximal token reduction and near-perfect retrieval on flat tables is the key reason TOON outperforms the markdown-table alternative for scraped data.

HTML Table to TOON: A Concrete Example

Consider a small scraped table of software package versions. Here is what the raw HTML looks like inside a code block, followed by the same data as TOON:

<!-- Raw HTML — tag overhead dominates, ~110 tokens for 4 rows -->
<table>
  <thead>
    <tr><th>package</th><th>version</th><th>license</th><th>weekly_downloads</th></tr>
  </thead>
  <tbody>
    <tr><td>react</td><td>18.3.1</td><td>MIT</td><td>28000000</td></tr>
    <tr><td>lodash</td><td>4.17.21</td><td>MIT</td><td>45000000</td></tr>
    <tr><td>axios</td><td>1.7.9</td><td>MIT</td><td>18000000</td></tr>
    <tr><td>zod</td><td>3.23.8</td><td>MIT</td><td>9500000</td></tr>
  </tbody>
</table>

// JSON — keys repeated 4× each, ~72 tokens for data alone
[
  {"package":"react","version":"18.3.1","license":"MIT","weekly_downloads":28000000},
  {"package":"lodash","version":"4.17.21","license":"MIT","weekly_downloads":45000000},
  {"package":"axios","version":"1.7.9","license":"MIT","weekly_downloads":18000000},
  {"package":"zod","version":"3.23.8","license":"MIT","weekly_downloads":9500000}
]

// Markdown table — pipes and separator row on every line, ~68 tokens
| package | version  | license | weekly_downloads |
| ------- | -------- | ------- | ---------------- |
| react   | 18.3.1   | MIT     | 28000000         |
| lodash  | 4.17.21  | MIT     | 45000000         |
| axios   | 1.7.9    | MIT     | 18000000         |
| zod     | 3.23.8   | MIT     | 9500000          |

// TOON — header declared once, plain values per row, ~30 tokens
packages[4]{package,version,license,weekly_downloads}:
  react, 18.3.1, MIT, 28000000
  lodash, 4.17.21, MIT, 45000000
  axios, 1.7.9, MIT, 18000000
  zod, 3.23.8, MIT, 9500000

The TOON representation is roughly half the tokens of JSON and removes the separator-row overhead entirely. To paste the same data as JSON into the free json2toon.co converter and get TOON output in one click, simply parse your scraped HTML table into a JSON array first, then convert.

Format Comparison: HTML vs Markdown vs TOON for LLM Extraction

The table below compares the three most common ways to pass scraped tabular data to an LLM, across the metrics that matter most for extraction workloads.

Sources: field retrieval accuracy figures from the official toonformat.dev benchmarks (5,016 LLM calls, four models). Markdown table token cost from the Improving Agents format benchmark.

The Scraping Pipeline: HTML Table to TOON in Practice

A typical scraping pipeline that feeds data to an LLM involves three steps: extract, transform, prompt. Here is where the format conversion fits:

1. Extract. Use a scraper (Playwright, Cheerio, BeautifulSoup) to select the <table> element and pull rows into a plain JavaScript or Python array of objects, one object per <tr>, with keys from the <th> cells.
2. Transform. Serialize the array as JSON, then convert to TOON. If you are working in JavaScript, use the @toon-format/toon package directly, or paste into the free converter for one-off work.
3. Prompt. Inject the TOON block into your system or user message. Because the schema is self-describing — the header line names every field and declares the row count — the model does not need a separate schema explanation for straightforward extraction tasks.

For tables that contain nested data — for example, a product table where one column holds a JSON object of attributes — the flat-table savings of 58.8% will not apply to the nested portion. The TOON nested data handling guide covers how TOON represents mixed structures and where the savings curve bends.

When TOON Is Not the Right Choice for Scraped Tables

TOON's advantage depends on two conditions: the table must be reasonably uniform (same fields across rows) and the payload must be large enough to amortize any format-instruction overhead. A 2026 arXiv paper (arXiv 2603.03306) identified a scaling threshold: below roughly 10 objects, the token cost of format instructions can exceed TOON's per-row savings, making JSON more efficient overall.

If the scraped table has irregular columns — some rows with extra fields, merged cells, or deeply nested sub-tables — savings drop toward the mixed-structure figure of 21.9%. In those cases, clean the data first, extract the uniform core to TOON, and pass the irregular remainder as JSON or prose. See the full TOON format comparison for a broader decision framework.

For purely flat scraped tables with no nesting at all, CSV is a legitimate alternative — every LLM understands CSV with zero instructions, and the CSV vs TOON comparison shows the boundary conditions precisely. TOON pulls ahead when the data has at least one level of nesting or mixed types.

Frequently Asked Questions