JSON has been with us for two decades as the lingua franca of APIs. But in the era of large language models with huge context windows, every character counts… and JSON turns out to be surprisingly expensive in tokens. That’s exactly where ZON (Zero Overhead Notation) comes in: a format designed specifically to talk to LLMs without wasting context.
ZON doesn’t try to reinvent the data model: it still represents objects, arrays, and primitives just like JSON. What it radically changes is how that data is written so models can read it with less noise and more signal.
What ZON is and what problem it solves
ZON is a human-readable text format that serializes the same data as JSON, but with three very clear goals:
- Minimize tokens consumed by an LLM.
- Eliminate parsing ambiguity, so the model doesn’t “hallucinate” structure.
- Be streaming-friendly, i.e., easy to generate and process as a stream.
According to its benchmarks, ZON typically achieves around 30–40% fewer tokens than JSON for the same content. And when you compare it to other AI-oriented formats like TOON, it can save an additional 25–35% on large datasets.
For applications that feed big chunks of context to models (user profiles, product catalogs, logs, configs…), that reduction translates into lower cost, faster responses, and more space left for instructions and reasoning.
How it compresses so much: tables, less syntax, and “for models” design
The magic of ZON is in how it represents data that’s very verbose in JSON.
1. Tabular arrays instead of repeating keys
Classic case: an array of objects with the same structure, e.g. users:
[
{ "id": 1, "name": "Alice", "active": true },
{ "id": 2, "name": "Bob", "active": false }
]
Code language: JSON / JSON with Comments (json)In JSON, the keys "id", "name", "active" are repeated on every row. ZON converts this into a table:
users:@(2):active,id,name
T,1,Alice
F,2,Bob
users:is the block name.@(2)indicates how many rows follow.active,id,nameare the column headers, declared once.- Each following line is a row with values in order.
For an LLM, this is much less text, but just as self-explanatory.
2. Minimal syntax, no unnecessary noise
ZON aggressively reduces brackets, braces, and commas. Instead of:
{ "config": { "env": "prod", "debug": false } }
Code language: JSON / JSON with Comments (json)you might see something like:
config:"{env:prod,debug:F}"
Code language: CSS (css)Nested objects are represented with a compact inline syntax between braces, but without redundant quotes, and booleans are single characters (T/F).
Fewer punctuation symbols means fewer tokens for the model.
3. Streaming-first by design
ZON is designed to be parsed byte by byte, without waiting for a big closing brace at the end of a massive block. That fits very well with:
- Streaming responses from an LLM.
- Pipelines where logs, events, or rows are processed incrementally.
Its structure lets parsers rebuild objects on the fly, something that’s a lot more awkward with strict JSON.
Real-world savings: tokens and LLM accuracy
The ZON authors have benchmarked the format against JSON, TOON, YAML, CSV, and XML with different models (GPT-4o, Claude 3.5, Llama 3…), measuring two things:
- Tokens consumed.
- Accuracy when extracting specific values (for example, “what is the email of user 17?”).
The results they publish:
- ZON achieves around 30–40% fewer tokens than JSON in aggregate tests.
- On large, nested datasets, it’s 25–35% more efficient than TOON.
- Both ZON and TOON reach 100% accuracy when retrieving values: no information is lost when compressing the structure.
In other words: same data, same answers, but with far less context consumed.
ZON vs other formats: the big picture
Here’s a high-level comparison of ZON with other common formats used around LLMs:
| Format | Data model | Token efficiency (vs JSON) | Human readability | LLM friendliness | Typical use cases |
|---|---|---|---|---|---|
| JSON | Objects, arrays, primitives | Baseline 100 | High, de-facto standard | Good, but very verbose and repetitive | APIs, configs, traditional web payloads |
| ZON | Same as JSON | ~30–40% fewer tokens than JSON; ~25–35% fewer than TOON on large datasets | Medium–high (some learning curve) | Very high: explicit structure, no ambiguity, LLM-first | Model context, prompts with many records, logs, analytics, complex tabular data |
| TOON | Table- and object-oriented | ~10–20% fewer tokens than JSON overall, but less efficient than ZON for big data | Medium | High, also LLM-oriented | Similar to ZON where TOON is already used as an intermediate format |
| YAML | Same as JSON, with sugar | Often slightly worse than JSON in tokens (more keywords and indentation) | High, very comfortable for humans | Medium: indentation and interpretation can confuse models | Human-edited config (DevOps, Kubernetes, etc.) |
| CSV | Simple flat tables | Very efficient for purely tabular data | Low for complex structures | Medium: fine for simple rows, bad for nesting | Simple exports, flat datasets, spreadsheets |
Note: These savings are approximate and based on ZON’s public benchmarks; the actual impact depends heavily on the type of data you send.
When ZON is worth considering
Some scenarios where ZON makes a lot of sense:
- Systems hitting the context window limit
Example: sending hundreds of support tickets, events, or user profiles to a model for summarization or classification. - Apps where token cost really hurts
If each model call drags in 10,000–50,000 tokens of structured context, cutting 30% can have a visible impact on the monthly bill. - Agents and pipelines with lots of structured data back-and-forth
Coordinators, tools, function calls… where JSON starts hogging too much space compared to instructions and reasoning. - Workloads with lots of “similar” rows
Arrays of homogeneous objects (users, products, logs…) are where ZON really shines thanks to its tabular encoding.
The caveats: adoption, tooling, and ecosystem
Of course, nothing comes for free:
- It’s a new format
Even though the spec is public and the design considered stable, the authors are clear that ZON is still evolving and not “frozen” as a formal standard. - Smaller ecosystem (for now)
Today there are official libraries for TypeScript and Python, plus some CLI tools and web playgrounds, but nothing like JSON’s massive ecosystem. - Learning curve for your team
Developers need to get used to reading tabular blocks and compact syntax. It’s not hard, but you do need a bit of training and good visualization tools.
That’s why ZON probably won’t replace JSON everywhere. It makes more sense as an internal format “to talk to models”, while keeping JSON for the outside world (public APIs, integrations, etc.).
In summary
- JSON is still king on the web, but it’s very expensive in tokens when used as a raw format to feed language models.
- ZON offers a minimalist, LLM-oriented alternative that:
- Preserves the same data model.
- Aggressively compresses arrays of objects.
- Strips away redundant syntax.
- Public benchmarks show around 30–40% savings vs JSON, and up to 25–35% extra savings vs TOON on complex datasets, all while keeping 100% retrieval accuracy.
If your application is starting to feel the context bottleneck—or your CFO is staring at the “AI tokens” line in the budget—ZON is worth testing as an intermediate format. Less noise, more signal… and the same data as always.