Developer Tools·4 min read

What Is TOON Format? JSON to TOON for LLM Prompts

Token-Oriented Object Notation, TOON for short, is a new serialization format built for one purpose: sending structured data to language models in fewer tokens. If you're wondering what is toon format doing that JSON doesn't, the trick is simple. Uniform arrays of objects stop repeating their keys on every record and become compact tables instead. The data is identical and converts back to JSON exactly, but on typical tabular payloads the token count drops 30 to 60 percent. This article covers how the encoding works, a real before and after, and the cases where plain JSON is still the right call.

Open the tool All insights

What is TOON format, exactly

A new format, honestly labeled.

TOON is an indentation-based serialization format: plain values are written as key: value lines, nesting is expressed with two-space indents instead of braces, and strings are only quoted when they'd otherwise be ambiguous. Arrays declare their length up front, so a list of three tags becomes tags[3]: a,b,c on a single line.

It's worth being straight about its status. TOON is young, defined by a community spec on GitHub rather than by a standards body, and it hasn't earned the two decades of tooling JSON has. That makes it a good fit for prompt payloads you control on both ends, and the wrong pick for public interfaces. Nothing about trying it locks you in, since conversion back to JSON is exact.

How TOON cuts LLM token costs

Stop paying for repeated keys.

Tokenizers charge for everything: braces, brackets, quotes, colons, and every repetition of every key. In a JSON array of 100 objects, each field name appears 100 times, wrapped in quotes each time. That overhead is pure cost, since the model learns nothing new from the 99th repetition of "price".

TOON's answer is tabular encoding. When every object in an array shares the same keys and holds only primitive values, the whole array collapses to a header line naming the fields once, followed by one delimited row per record. That single change is where most of the savings live, and it's how toon cuts llm token costs by 30 to 60 percent on the data portion of a prompt.

A worked example: two users, one header row

Input and output, side by side.

Start with this JSON: {"users":[{"id":1,"name":"Alice"},{"id":2,"name":"Bob"}]}. Paste it into the converter and click Convert to TOON. The output is three short lines: users[2]{id,name}: as the header, then 1,Alice and 2,Bob indented beneath it. The braces, brackets, and all four quoted key repetitions are gone, while the declared count and field list preserve the structure.

Even on this toy sample the savings panel reports a real drop against minified JSON, and the gap widens with every row added, because each new record costs only its values plus a newline. Run your own payload through it; flat arrays from a database or an API are where the numbers get dramatic.

Mistakes that shrink your TOON savings

Where conversions disappoint.

None of these are flaws in the format so much as mismatched expectations. TOON is a specialist: it exists to make large, uniform, tabular data cheap inside prompts, and it should be judged on exactly that job.

Converting deeply nested or ragged data. Arrays whose objects carry different keys can't use the tabular form and fall back to list items, saving little.
Comparing against pretty-printed JSON. The honest baseline is minified JSON, which is what this converter measures against.
Sending TOON to a strict JSON consumer. Function-calling schemas, REST endpoints, and tool outputs expect JSON and will reject anything else.
Leaving the model guessing. If the prompt never says the block is TOON, you're relying on the model to infer the format on its own.
Micro-optimizing tiny payloads. Below a few hundred tokens the savings rarely matter; the technique pays off on big tables.

TOON vs JSON for prompts: three practical tips

Getting the most from the converter.

First, try the tab delimiter. Tokenizers usually merge a tab into a single token, and tabs almost never appear inside real values, so fewer cells need quoting. The delimiter is declared in the array header, so decoding is unaffected. Second, spend one prompt line on context, something like: the data below is in TOON, a compact tabular notation. It costs a dozen tokens and removes any ambiguity for the model.

Third, split your traffic sensibly. The toon vs json for prompts question isn't either-or: keep JSON for anything a parser consumes, and convert the bulky read-only context, the product tables and result sets, where the token meter actually runs. Measured on real payloads, that split captures nearly all the benefit with none of the compatibility risk.

Where the JSON to TOON Converter sits among the JSON tools

Related tools on this site.

Validate and inspect before you convert: the JSON Validator confirms your payload parses, and the JSON Formatter makes it readable enough to sanity-check the values. If the data is headed for a spreadsheet rather than a model, JSON to CSV is the right table format, since Excel doesn't read TOON.

The JSON Minifier produces the baseline this converter measures against, and sometimes minified JSON alone is enough when data is small or deeply nested. For configuration meant for human editing, JSON to YAML optimizes for readability the way TOON optimizes for token count: the same family of conversions, tuned for different budgets.