TOON vs YAML: Which Format Uses Fewer LLM Tokens?

TOON vs YAML: both formats use indentation instead of braces, but YAML repeats every key for every list item, while TOON (Token-Oriented Object Notation) declares the fields of a uniform list once in a header and writes each item as one row. In the official TOON v4.1 benchmark that makes TOON prompts about 29% smaller than YAML (2,474 vs 3,487 tokens on average) with accuracy roughly equal (72.2% vs 70.1%). Use YAML for config that humans write; use TOON for data you send to an LLM.

Want to see it on your own file? Paste it into the YAML to TOON converter.

In the pantheon of data serialization, YAML (YAML Ain't Markup Language) stands as the undisputed king of human readability. It conquered the world of DevOps, becoming the standard for Kubernetes, Ansible, and GitHub Actions. But in the age of Generative AI, where data is read by machines more often than humans, strict readability can become a liability.

TOON approaches data from a different angle. It asks: "What if we kept the whitespace-friendly nature of YAML for structure, but optimized the data density for Tokenizers?" The result is a format that feels familiar to YAML developers but performs drastically better for LLM Context Windows.

The Token Tax: Arrays of Objects

The biggest difference comes when representing lists of data—the bread and butter of RAG context.

YAML is row-oriented and repetitive. To list three users, you must repeat the keys id, name, and role three times.

users:
  - id: 1
    name: Alice
    role: admin
  - id: 2
    name: Bob
    role: user
  - id: 3
    name: Charlie
    role: user

Token Count: ~60 tokens.
Every repetition - id: costs tokens. In a list of 100 items, you pay this tax 100 times.

TOON is Header-Oriented (like CSV) but nested (like JSON). It defines the schema once.

users[3]{id,name,role}:
  1,Alice,admin
  2,Bob,user
  3,Charlie,user

Token Count: ~35 tokens.
Savings: ~40% in this example.

This "Header Row" optimization allows TOON to combine the readability of YAML with the density of CSV. For an LLM with a 128k context window, a 40% saving like this one lets you fit about 1.7x as much data in the prompt.

Advanced Literals: Handling Long Strings

One of YAML's best features is its handling of long strings (like prompt templates or code snippets) using Block Scalars. TOON takes a simpler approach with a single rule.

YAML: The confusing | vs >

YAML has two symbols for blocks:
| (Literal Style): keeps newlines.
> (Folded Style): replaces newlines with spaces.
Plus modifiers: |-, |+, >-. It's hard to remember which is which.

TOON: One Quoted String with Escapes

TOON has no block scalars or triple quotes. A multi-line value is a normal double-quoted string with JSON-style escapes (\n, \", \\), so there is only one way to write it and nothing to remember.

description: "This is a long text block.\nIt preserves newlines exactly as written.\nNo complex modifiers needed."

Benchmarks: The Real Cost of "Clean"

We ran a benchmark comparing YAML and TOON on a variety of industry-standard datasets.

The takeaway: If your data is a single object (like a K8s config), YAML is fine (only 7% worse). If your data is a List of Objects (like most AI context), YAML is disastrously inefficient (50% worse in our catalog test).

The official TOON v4.1 benchmark shows a smaller average gap across mixed datasets: prompts averaged 3,487 tokens as YAML versus 2,474 as TOON, about 29% fewer, with accuracy roughly equal (70.1% vs 72.2%).

Safety: The yaml.load() Vulnerability

A hidden danger of YAML is that in many languages (like Python and Ruby), the default load() function is unsafe. It can instantiate arbitrary objects and execute code.

!!python/object/apply:os.system
args: ['rm -rf /']

If you blindly parse untrusted YAML, you are vulnerable to RCE (Remote Code Execution).

TOON is data-only. It has no mechanism to instantiate classes or call functions. It is safe by design to parse untrusted TOON input from an LLM or user.

When to Stick with YAML

Despite TOON's advantages, YAML is not going anywhere.

• Ecosystem Compatibility: If you are writing a github-action.yml, you must use YAML.
• Short Configs: For a 10-line config file, the overhead of defining header rows in TOON (users[]{...}) might feel like overkill.
• Anchors/Aliases: If you rely heavily on &base_config and <<: *base_config to reduce duplication in manual editing, YAML wins.