TOML vs TOON: Config Format vs LLM Data Format Compared

TOML vs TOON: TOML (Tom's Obvious, Minimal Language) is a configuration format for files people edit by hand, such as Cargo.toml and pyproject.toml. TOON (Token-Oriented Object Notation) is a data format for LLM prompts. The biggest practical difference is lists of objects: TOML repeats a [[table]] header and every key for each item, while TOON writes the keys once and then one row per item. Use TOML for config, TOON for data you send to a model.

You can convert a TOML file in one step with the TOML to TOON converter.

In the world of modern software development, TOML (Tom's Obvious, Minimal Language) has carved out a niche as the gold standard for configuration files. It is the language of choice for Rust's Cargo, Python's Poetry and pyproject.toml, and static site generators like Hugo. Its design goal is to be "unambiguous" and "easy to parse."

TOON, on the other hand, was not designed for configuration. It was designed for Communication between humans and Large Language Models (LLMs). While they look superficially similar (both avoid braces), they are optimized for radically different constraints. This post compares them byte-for-byte to help you decide which one to use in your AI pipeline.

The Philosophy of Explicit vs Density

TOML's creator, Tom Preston-Werner, stated that TOML is designed to map unambiguously to a hash table. It prioritizes clarity over brevity.

TOON optimizes for Semantic Density. It asks: "What is the minimum number of tokens required to convey this information to an intelligent agent without losing structure?"

The "Array of Tables" Bottleneck

The most dramatic difference appears when you need to represent lists of objects—which is the most common data structure in RAG (e.g., retrieving 50 relevant documents).

TOML: The Verbose Repeater

In TOML, a list of objects is called an "Array of Tables" and uses the `[[syntax]]`.

[[documents]]
id = "doc_1"
title = "Introduction to TOML"
score = 0.98

[[documents]]
id = "doc_2"
title = "Why Rust uses TOML"
score = 0.95

[[documents]]
id = "doc_3"
title = "Comparing JSON and TOML"
score = 0.92

Notice that for every single item, we repeat: 1. The header [[documents]] 2. The key id = 3. The key title = 4. The key score =

This means the token cost grows linearly with the number of fields multiplied by the number of items.

TOON: The Header Optimizer

TOON borrows the best idea from CSV (headers) and applies it to structured data.

documents[3]{id,title,score}:
  doc_1,Introduction to TOML,0.98
  doc_2,Why Rust uses TOML,0.95
  doc_3,Comparing JSON and TOML,0.92

Here, the keys define the structure once. The data follows.
Result: 44% reduction in token count for this simple example. Across larger datasets, the official TOON benchmark measures about 43% fewer tokens than JSON on average, and up to about 59% on flat uniform tables such as database rows.

Syntax Showdown

1. Nesting

TOML handles deep nesting via "Dotted Keys" or subsection headers.

# TOML
[server.database.primary]
host = "10.0.0.1"
port = 5432

This is great if you want to override a single value deep in a config. But if you are trying to visualize the whole tree, it can be confusing as headers can appear anywhere in the file.

TOON uses strict indentation (like YAML/Python).

# TOON
server:
  database:
    primary:
      host: 10.0.0.1
      port: 5432

This visual hierarchy matches how LLMs (and humans) typically visualize trees.

2. Dates and Times

TOML has a major advantage here. It supports RFC 3339 dates natively.

dob = 1979-05-27T07:32:00Z

When parsed, this becomes a native Date object in Python/JS.

TOON treats dates as strings by default (to keep the parser simple and fast).

dob: "1979-05-27T07:32:00Z"

You have to rely on the application layer (or a Schema) to cast it to a Date object.

Token Economics: The Math

Let's break down the cost for a standard "Retrieval" payload of 20 chunks.

• JSON: ~3,000 tokens (braces, quotes, repeated keys).
• TOML: ~3,200 tokens (bracket headers, repeated keys, equals signs).
• YAML: ~2,800 tokens (cleaner, but still repeats keys).
• TOON: ~1,600 tokens.

Why is TOML more expensive than JSON? Because [[tablename]] adds significant overhead for every item. TOML is designed for short lists, not long datasets.

Use Cases

When TOML Wins

Application Configuration.

If you are building a tool and you need a config file for users to edit, use TOML.

# config.toml
debug = true
title = "My App"

It is foolproof. Users cannot mess up indentation (TOML doesn't care about indentation). It is unambiguous.

When TOON Wins

AI System Prompts & Context APIs.

If you are inserting data into a System Prompt:

You are an assistant. Here is the user's recent order history to help you answer their question:

orders[3]{id,date,total,status}:
  101,2023-10-01,$45.00,Shipped
  102,2023-11-15,$12.50,Delivered
  103,2023-12-05,$99.99,Processing

The LLM understands this perfectly. It uses minimum tokens. It clearly delineates the data. Using TOML here would waste tokens and distract the model with administrative syntax.

Conclusion

TOML is a triumph of Human-Computer Interaction design. It makes configuring software a joy.

TOON is a triumph of LLM-Computer Interaction design. It makes transmitting data to models efficient and structured.

Do not replace your Cargo.toml with TOON. But do not serialize your 10,000 vector search results into TOML. Use the right tool for the job. When TOML or JSON data needs to go into a prompt, run it through the TOML to TOON or JSON to TOON converter and check the difference in the TOON token calculator.