Toon: A Lightweight Data Format That Helps Cut LLM Token Costs

When working with LLMs, even small details—like how you format your data—can add up to noticeable differences in cost and performance. One of the new formats people have been experimenting with is called Toon(Token-Oriented Object Notation), and it’s gaining attention because of how compact it is. It conveys structured information like JSON or XML, but with fewer characters, which usually means fewer tokens.

This doesn’t replace established formats. JSON and XML are excellent for APIs, external integrations, and strict data handling. Toon simply offers a lighter alternative specifically for situations where data is being processed inside an LLM prompt or response, where size matters more than strict formal structure.

Below, I’ll walk through what Toon looks like, how to write it, how to create arrays and lists, how nesting works, and how it compares to JSON and XML—using straightforward language so the concepts click easily.

What Is Toon, in Simple Terms?

Toon is a compact way of writing structured information.
If JSON and XML aim for full clarity and standardization, Toon aims for minimal overhead. It focuses on giving the model the data it needs without the extra symbols that traditional formats include for compatibility with programming languages and parsers.

A basic Toon object looks like this:

name:Luna;age:3;color:silver

No quotes, no commas, no braces around the whole thing.
Still understandable, still structured—just lighter.

How to Write Toon Data

Here’s a breakdown of the different building blocks.

1. Basic Toon “objects”

A Toon object is simply a sequence of key:value pairs separated by semicolons:

name:Luna;age:3;color:silver

If a value contains spaces, wrap it in parentheses so it stays together:

title:(Chief Snack Manager)

That’s all you need for a standard object.

2. Toon Arrays

Arrays in Toon use square brackets and separate items using the pipe symbol |:

pets:[cat|dog|ferret]

More complex items can also be placed inside an array:

tasks:[name:clean;time:10 | name:feed;time:5]

Each item can be its own structured object.

3. Toon Lists

Toon also supports lists, which behave like arrays but preserve order more explicitly and allow repeated values without any ambiguity.

Lists use angle brackets:

shopping:<milk|eggs|eggs|bread>

Use lists when the exact sequence matters or when duplicates are intentional.

4. Nested Toon Structures

Toon allows nesting using curly braces {}:

user:{name:Luna;stats:{speed:9;stealth:10}}

This keeps nested relationships clear while still avoiding most of the bulk found in JSON or XML.

Toon vs JSON vs XML: What’s the Difference?

All three formats serve a purpose, but they’re shaped by different goals.

XML

XML is very explicit.
It prioritizes structure, clarity, and machine-verified consistency. That’s why it uses opening and closing tags:

<cat>
  <name>Luna</name>
</cat>

Great for document-like data and environments that require strict validation.

JSON

JSON is lighter than XML and is widely used in web APIs:

{ "name": "Luna", "age": 3 }

It’s familiar, readable, and supported everywhere—but it still includes quotes, commas, and braces that add up in token-based contexts.

Toon

Toon takes a different approach. It focuses on reducing the number of characters used to express the same information:

name:Luna;age:3

It keeps things understandable while minimizing overhead.
This makes it practical when your main target is an LLM rather than an external system or parser.

Simple Comparison

Each has strengths; Toon is simply optimized for a different environment.

Why Toon Reduces Token Costs (Clear Example)

Let’s compare the same data in JSON and Toon.

JSON version:

{
  "name": "Luna",
  "age": 3,
  "color": "silver"
}

This includes:

• 2 curly braces
• 6 quotation marks
• 2 commas
• Extra whitespace
• Repeated keys in quotes

These all become individual tokens.
A short object like this often lands around 24–28 tokens.

Toon version:

name:Luna;age:3;color:silver

Much fewer symbols, no quotes, no commas, no braces.
This usually ends up around 10–12 tokens.

Scaling the Example

If you had 100 objects of this shape:

• JSON: ~25 tokens × 100 = 2500 tokens
• Toon: ~11 tokens × 100 = 1100 tokens

You save about 1400 tokens just by changing the format.

For large prompt-based systems, tool outputs, or inline metadata inside LLM workflows, this can noticeably reduce costs over time.

When Toon Makes Sense (and When It Doesn’t)

Use Toon When:

• You’re passing structured info into an LLM via a prompt.
• You need consistent data with minimal token count.
• You’re building classification, extraction, or reasoning workflows where structure matters but full syntactic formality doesn't.
• You want to shrink big chunks of repeated data.

Avoid Toon When:

• The data is part of a public API.
• You need schema validation or strict typing.
• You’re sharing the data with external systems that expect JSON or XML.
• Programmers need long-term maintainability outside LLM-based tools.

Toon isn’t trying to replace the established formats—it’s just optimised for a different environment.

Final Thoughts

Toon is a lightweight, practical format that fits well into LLM-focused pipelines. It keeps structure clear but trims away most of the characters that increase token count. JSON and XML still dominate traditional software systems, and they should—they’re reliable and standardised.
But when your goal is to communicate structured data inside an LLM prompt as efficiently as possible, Toon offers a noticeably smaller, cleaner alternative.