TOON

Token-Oriented Object Notation is a compact, lossless way to represent JSON-style structured data for language models. It reduces repeated syntax by declaring the field schema once and then expressing uniform records in a row-oriented layout, which makes it especially efficient for tool output and other tabular data.

What TOON Is Optimised For

TOON is designed for structured, row-oriented data that repeats the same fields across many records. Its main advantage is that it declares the schema once, then minimizes repetition so model output stays compact without losing the ability to reconstruct the original structure exactly.

That makes TOON especially useful when a language model must emit tabular data, tool results, or records that would otherwise be bloated by repeated JSON keys. The format is not trying to replace JSON everywhere, it is trying to preserve JSON-style meaning while reducing token cost and verbosity.

How TOON Works as a Data Representation

The key design choice is schema-first encoding. Instead of repeating field names on every row, TOON lists the fields once and then serializes each record against that field order. For data with uniform shape, this produces a smaller and cleaner representation than conventional object-per-row JSON.

Because the mapping is explicit, TOON can remain lossless, which means the original structured data can be recovered without ambiguity. That distinction matters: compression alone is not enough if the structure becomes harder to parse or if field meaning is lost during round-trip conversion.

In practice, TOON sits between human-readable structured text and machine-efficient serialization. It is most compelling when outputs are predictable, schema-bound, and generated in volume, rather than when fields vary widely from record to record.

Why TOON Helps LLM and Tool Output

Language models often spend a surprising amount of output budget repeating the same labels in lists, tables, and API-like responses. TOON reduces that overhead by aligning the structure of the data with the way models already emit sequences, which can make responses shorter and easier to fit into context windows.

This is useful for tool output, because tool responses are frequently regular, repetitive, and easy to normalize into rows. It also helps when downstream code needs a stable structure but the generating system benefits from a more token-efficient representation than full JSON objects.

TOON is therefore best understood as a serialization choice with operational consequences, not merely a formatting preference. The payoff is lower verbosity, but the trade-off is that the consumer must understand the notation and the schema contract that drives it.

Design Trade-offs and Practical Limits

TOON works best when the data shape is consistent. If records contain many optional fields, nested structures, or frequent exceptions, the row-oriented advantage diminishes and the notation can become less elegant than JSON or another native structure.

It also introduces a dependency on schema agreement. Anyone reading or producing TOON must know the field order and the intended reconstruction rules, otherwise the compactness becomes a source of confusion rather than efficiency.

For that reason, TOON is strongest in controlled pipelines where the producer and consumer are aligned, especially when the goal is to reduce repetitive syntax without changing the underlying semantics of the data.

Related resources from NHI Mgmt Group

• How should security teams decide whether to use TOON or JSON for AI agent input?