TOON

Every token you send to an LLM costs money, and JSON, the default way developers pass structured data into a prompt, is wasteful about it. Each object repeats its field names, braces and quotes pile up, and a table of a hundred rows pays for the same keys a hundred times. As context windows grow and people stuff more data into prompts, that overhead becomes a measurable line item. TOON, short for Token-Oriented Object Notation, is a serialization format built specifically for this problem. It encodes the same data model as JSON, objects, arrays and primitives, with deterministic lossless round-trips, but lays the bytes out so a tokenizer counts fewer of them. The project frames it plainly: keep using JSON in your code, and encode to TOON only at the boundary where data enters the model.

TOON fuses two ideas. For nested structures it uses YAML-style indentation instead of braces, dropping most quotes and punctuation. For uniform arrays of objects, the part that matters most, it switches to a CSV-like table: it declares the array length and the field names once, then streams each record as a row of comma-separated values. A hikes array becomes one header line followed by three data rows rather than three fully repeated objects. The length marker and the field header are not just compression, they double as a schema the model can check against, which is why the project leans on them as guardrails for detecting truncation or missing fields. The format ships with a formal spec, a CLI with token stats, SDKs across TypeScript, Python, Go, Rust, .NET, Java and Swift, a VS Code extension and a Tree-sitter grammar.

The natural audience is anyone feeding large, regular datasets into prompts and watching the token bill. Think search results, database query rows, product catalogs, event logs, time-series tables or lists of GitHub repos: data where the same fields recur across many records. A retrieval-augmented pipeline that injects fifty order records, or an agent that dumps a hundred-row query result into context, is exactly where the tabular layout pays off. Because the saving happens at the format level, it is model-agnostic and needs no proxy or SDK on the inference side, so it slots into existing prompt-building code regardless of which provider you call. The broad language coverage and the editor tooling lower the barrier for teams who want to standardize on it, and the included MCP proxy hints at agent tool-call responses as a target where verbose JSON is a recurring cost.

The honesty test is in the caveats, and the project is upfront about them. TOON only wins on uniform arrays of objects. Feed it deeply nested config, irregular or semi-uniform data, or mostly free text, and the savings shrink or vanish, with the README showing JSON beating TOON on a deeply nested configuration sample. For purely tabular data, plain CSV is smaller, since TOON adds roughly five to ten percent overhead for its structural metadata. There is also a latency caveat: fewer tokens does not always mean faster, and quantized local models may process compact JSON quicker. Two practical frictions remain. Adoption needs buy-in from both the producer and consumer of the data, and the accuracy and token figures, including the headline 76 percent at around 40 percent fewer tokens, are the project's own benchmarks, so treat them as a starting point to reproduce.

The honest framing is that TOON has no single commercial alternative, because its real competitor is JSON itself, plus CSV for flat tables and prompt-compression services that operate at a different layer. Against JSON, TOON is a targeted optimization rather than a replacement: you adopt it precisely where you are paying repeatedly for uniform array structure, and you leave JSON in place everywhere else, including in your application logic. It makes sense to reach for it when token cost on tabular prompt data is a real and recurring expense and you can measure the saving on your own payloads and tokenizer. It is too early, or simply the wrong tool, when your data is mostly nested, irregular or free text, when CSV already covers your flat tables, or when latency rather than token count is the binding constraint. Benchmark first, then decide.