Understanding TOON: A Token-Friendly Data Format for AI Applications

When we work with web applications, JSON is everywhere.

We send JSON from the frontend to the backend. We store JSON in configs. We inspect JSON in browser devtools. As frontend engineers, JSON feels almost like the default language of data.

But recently, while reading about Large Language Models(LLMs) and token optimization, I came across a new format called TOON.

TOON is not trying to replace JSON everywhere. It is more useful as a compact way to represent JSON-like data when sending structured information to LLMs.

In this article, let’s understand what TOON is, why it exists, how it looks compared to JSON, and when we should or should not use it.

What is TOON?

TOON stands for Token-Oriented Object Notation.

It is designed with tokens in mind. When we send data to an LLM, the model does not read the text exactly like we do. It breaks text into tokens. More tokens usually means more cost, more context usage, and sometimes slower processing.

JSON is very clear for machines and developers, but it can be verbose for LLM prompts.

For example, JSON uses many repeated symbols:

{
  "users": [
    {
      "id": 1,
      "name": "Kasun",
      "role": "admin"
    },
    {
      "id": 2,
      "name": "Nimal",
      "role": "viewer"
    }
  ]
}

This is perfectly fine in an API. But for an LLM prompt, we are spending tokens for repeated braces, quotes, commas, and repeated field names like id, name, and role.

The same data can be represented using TOON like this:

users[2]{id,name,role}:
  1,Kasun,admin
  2,Nimal,viewer

This looks like a mix of YAML and CSV.

The structure is still there. But the repeated object keys are declared only once.

If the data structure is repeated, do not repeat the structure again and again.

This is very common in real applications.

Think about a list of users:

[
  { "id": 1, "name": "Kasun", "status": "active" },
  { "id": 2, "name": "Nimal", "status": "inactive" },
  { "id": 3, "name": "Amal", "status": "active" }
]

Each object has the same keys: id, name, and status.

In JSON, those keys are repeated for every object.

In TOON, we can declare the keys once:

[3]{id,name,status}:
  1,Kasun,active
  2,Nimal,inactive
  3,Amal,active

Here:

• [3] says there are 3 records.
• {id,name,status} says these are the fields.
• Each next line is one record.

This is why TOON can be token-efficient for repeated data.

One important thing to understand is that TOON is not a completely different data model. It can represent the same basic data types as JSON:

• strings
• numbers
• booleans
• null
• objects
• arrays

So we can think of TOON as another way to serialize JSON-like data.

In normal application code, we may still keep JSON as the main format. Then, when we need to send data to an LLM, we can convert JSON into TOON.

JSON for application communication. TOON for compact LLM context.

Objects in TOON

Simple objects are easy to read.

JSON:

{
  "id": 101,
  "name": "Notebook",
  "available": true
}

TOON:

product:
  id: 101
  name: Notebook
  available: true

This part looks similar to YAML. We do not need braces or quotes in many normal cases.

Nested objects also use indentation:

product:
  id: 101
  name: Notebook
  available: true

So for plain objects, TOON mainly gives us a cleaner text format.

But the bigger win comes with arrays.

Arrays in TOON

Primitive arrays are represented inline.

JSON:

{
  "tags": ["frontend", "react", "typescript"]
}

TOON:

tags[3]: frontend,react,typescript

Again, [3] tells us the array length. This length is useful because an LLM can use it as a small validation hint. If the array says [3], but only two values are present, something is wrong.

For arrays of objects, TOON can use tabular format.

JSON:

{
  "orders": [
    { "id": 101, "item": "Mouse", "qty": 2 },
    { "id": 102, "item": "Keyboard", "qty": 1 }
  ]
}

TOON:

orders[2]{id,item,qty}:
  101,Mouse,2
  102,Keyboard,1

This is the place where TOON starts to feel useful.

For LLM input, this gives both compactness and structure.

More advanced example:

JSON:

{
  "tenant": "tenant1",
  "users": [
    { "id": 1, "name": "Kasun", "role": "admin" },
    { "id": 2, "name": "Nimal", "role": "viewer" }
  ],
  "meta": {
    "total": 2,
    "source": "console"
  }
}

TOON:

tenant: carbon.super
users[2]{id,name,role}:
  1,Kasun,admin
  2,Nimal,viewer
meta:
  total: 2
  source: console

TOON tries to take useful parts from YAML and CSV for LLM prompts.

Where TOON is useful

TOON is useful when we need to pass structured data to an LLM.

Some examples:

• sending a list of products to an AI assistant
• passing user records for analysis
• providing logs or events to summarize
• giving test data to an LLM
• passing search results into an AI workflow

In these cases, we are not using TOON as an API response format for browsers. We are using it as a prompt input format.

For example, imagine we want to ask an LLM:

“From this order list, find the top selling item.”

Instead of sending a large JSON array, we can send a TOON version of the same data. The model still gets the structure, but with fewer repeated tokens.

When TOON may not be the best option

TOON is not always better than JSON.

If the data is deeply nested or not uniform, TOON can lose some of its compactness.

For example:

{
  "user": {
    "profile": {
      "name": "Kasun",
      "preferences": {
        "theme": "dark",
        "notifications": {
          "email": true,
          "sms": false
        }
      }
    }
  }
}

This kind of data does not have a repeated table-like structure. In such cases, JSON or YAML may be equally good or sometimes better.

TOON gives the biggest benefit when arrays contain many objects with the same fields.

So before using TOON, we should ask:

“Is my data mostly repeated records?”

If yes, TOON can be a good fit.

If no, JSON may be simpler.

Should we use TOON in frontend applications?

As a frontend engineer, my first instinct was to think about API communication.

Can we send TOON from backend to frontend instead of JSON?

Technically, we can convert between formats if libraries are available. But practically, JSON is still the better default for APIs.

JSON has native browser support through JSON.parse and JSON.stringify. It is supported everywhere. Tooling is mature. Debugging is easy.

So I would not use TOON to replace JSON in normal REST APIs or frontend-backend communication.

But I would consider TOON in AI-related frontend features.

For example:

• A frontend app collects table data.
• The app sends that data to an AI endpoint.
• The backend converts the JSON payload into TOON before calling the LLM.
• The LLM receives a smaller and cleaner prompt.

That feels like a more practical use case.

Final thoughts

TOON is an interesting format because it comes from a very practical problem.

LLMs are now part of many applications. We pass more and more structured data into prompts. When the data gets larger, token usage becomes important.

JSON is still the default format I would use in application code. But when sending repeated structured data to an LLM, TOON is worth looking at.

The best part is that the concept is not hard to understand.

If you know JSON, YAML, and CSV, TOON feels like a combination of those ideas:

• JSON data model
• YAML-like indentation
• CSV-like rows for repeated objects
• extra structure hints like array length and field names

That makes it a nice format to learn, especially for developers building AI-powered features.

Hope this gave you a simple introduction to TOON. In a future article, we can look at how to convert JSON to TOON in a JavaScript or TypeScript application.

Peace ✌️