JSON vs TOON: Token Counts for LLM Prompts, Measured
TOON (Token-Oriented Object Notation) is a text encoding of the same data JSON holds, designed to use fewer tokens when you put data in an LLM prompt. It wins on arrays of objects that share the same fields, because it writes the field names once and then one row per item. On nested or irregular data it can use more tokens than minified JSON. Keep JSON in your code and APIs, and consider TOON only for data you paste into prompts, after measuring on your own payloads.
What TOON looks like
Five user records in JSON:
The same data from the official encoder (@toon-format/toon 4.4.0):
[5] declares the number of rows and {id,name,role,active} declares the fields once. Nested objects use indentation like YAML, and a list of plain values goes on one line, such as tags[2]: a,b. The TOON README gives the file extension as .toon and a provisional media type of text/toon.
Measured token counts
I counted tokens with the gpt-tokenizer package using the o200k_base encoding, the same tokenizer TOON's own benchmarks use. Other model families tokenize differently, so treat the counts as relative.
| Data | Pretty JSON (2-space) | Minified JSON | TOON | CSV |
|---|---|---|---|---|
| 5 user records (above) | 166 | 87 | 54 | 39 |
| 1 nested order (below) | 136 | 75 | 92 | not possible |
Two things stand out. First, the baseline matters. Against pretty-printed JSON, TOON looks like a huge saving, but simply minifying the JSON already cut the user records from 166 to 87 tokens. Second, on the nested order TOON used 17 more tokens than minified JSON. This is the order:
and its TOON, where the two items have different fields and fall back to a list:
When TOON helps
- Long arrays of same-shape records, such as table rows, search results, log lines or product lists. The TOON README calls this its sweet spot.
- Checking the model saw everything. The
[N]row count and the field list let a decoder notice truncated or malformed rows, which the README lists as a design goal.
When to stay on JSON
- Deep or irregular nesting. The README says compact JSON often wins there, and the order above shows it.
- Purely flat tables. CSV is smaller: 39 tokens against TOON's 54 for the user records. The README describes TOON's extra cost over CSV as the price of declared lengths and field lists.
- Model output you will parse. Structured output features from model providers enforce JSON against a JSON Schema. See getting structured JSON output from an LLM.
- Latency-sensitive setups. The README notes some deployments, notably local or quantized models, process compact JSON faster despite the higher token count.
- Everything outside the prompt. Every language and tool reads JSON. TOON needs a library.
How to convert JSON to TOON
From the command line, the official CLI prints TOON and an estimate of the tokens saved:
In JavaScript or TypeScript:
Cheaper wins to try first
Before adding a new format to your pipeline, try the ones you already have:
- Minify. The JSON minifier removes whitespace. In the test above that alone roughly halved the token count.
- Drop fields the model does not need. IDs, timestamps and URLs often cost more tokens than the values the model actually uses.
- Send flat tables as CSV. For a list of flat records, the JSON to CSV converter gives the smallest text of the four formats measured here.
FAQ
What does TOON stand for?
Token-Oriented Object Notation.
Is TOON lossless?
It encodes the JSON data model, and the README states round-trips are lossless. Both samples here decoded back to identical JSON.
Does TOON replace JSON?
No. Its own README describes it as a translation layer: use JSON in your programs and encode it as TOON for LLM input.
Is TOON better than CSV?
For flat tables, CSV is smaller. TOON adds row counts and field headers, and unlike CSV it can represent nested data.