TOON

TOON vs JSON: Byte-Level Efficiency Model ​

A mathematical analysis of TOON's byte efficiency compared to JSON across different data structures.

Overview ​

Large Language Models increasingly rely on structured data for inference and function calling. However, standard formats like JSON introduce significant verbosity that inflates token usage and inference costs. This analysis presents a formal mathematical comparison between TOON and JSON to evaluate whether TOON achieves quantifiable efficiency gains by eliminating structural redundancy.

Under the assumptions described below (compact JSON, canonical TOON, ASCII keys and punctuation, shallow to moderate nesting, and mostly unquoted TOON strings), TOON's structural overhead is lower than compact JSON for the structure families analyzed here, except arrays of arrays.

Key Findings ​

• Tabular arrays represent TOON's optimal use case, with efficiency gains scaling linearly with both row count and field count.
• Simple objects and primitive arrays show consistent byte reduction, with savings proportional to the number of fields or elements.
• Nested objects benefit from reduced overhead, though efficiency decreases with depth due to indentation costs; at sufficient depth, compact JSON can become smaller.
• Arrays of arrays are the only structure where TOON is less efficient than JSON in this analysis, due to TOON's explicit list markers and inner array headers.

Methodology ​

We define recursive byte-length functions $L_{\text{json}}$ and $L_{\text{toon}}$ for both formats, then derive the efficiency delta:

Where $\mathrm{\Omega }$ represents the data structure under comparison. If $\mathrm{\Delta }>0$, TOON uses fewer bytes than JSON for that structure.

Think of this as a simplified structural model: we strip away real-world noise and ask, "if you only count structural characters, how do JSON and TOON compare?"

Formal Notation ​

Data Model ​

Let $\omega$ be a primitive value such that $\omega \in \{\text{string, number, boolean, null}\}$.

Let $\mathcal{O}$ be an object composed of $n$ key-value pairs:

Let $\mathcal{A}$ be an array composed of $n$ elements:

Where:

• $k_i$ is a key (string)
• $v_i$ can be a primitive value $\omega$, an object $\mathcal{O}$, or an array $\mathcal{A}$

Therefore: $v_i\in \{\omega ,\mathcal{O},\mathcal{A}\}$

String Length ​

Let $\mathcal{S}$ be the set of valid Unicode strings. For any string $x\in \mathcal{S}$, we denote $|x{|}_{\text{utf8}}$ as the byte-length of $x$ under UTF-8 encoding.

Integer Length ​

Let $n\in {\mathbb{Z}}_{\ge 0}$ be a non-negative integer. The number of bytes required to represent $n$ in decimal format is:

JSON Size Functions ​

For a flat object of $n$ keys:

Where $L_{\text{str}}(k)$ is the length of the key including its mandatory quotes:

Primitive Values in JSON ​

When $v_i$ is a primitive data type $\omega$:

Arrays in JSON ​

When $v_i$ is an array $\mathcal{A}$:

TOON Size Functions ​

For a flat object of $n$ keys:

Where $L_{\text{str}}(k)$ is the length of the key (no quotes required for simple keys):

Primitive Values in TOON ​

When $v_i$ is a primitive data type $\omega$:

Simple Arrays in TOON ​

Here $L_{\text{toon}}(\mathcal{A})$ refers to the length of the whole field line key[N]: ..., not just the array value.

When $v_i$ is a simple array $\mathcal{A}$:

Tabular Arrays in TOON ​

When $v_i$ is an array of objects with $m$ fields:

Note: The term $2n$ assumes an indentation size of 2 spaces.

Efficiency Analysis by Structure ​

Each subsection below focuses on a particular structure family, states the resulting formula, and shows a small example. Intuitively, TOON tends to win when it can:

• avoid repeating keys (tabular arrays),
• avoid quoting keys and many values,
• and replace braces with indentation,

and tends to lose when it pays a fixed overhead per element (arrays of arrays) or deep indentation (heavily nested configs).

Simple Objects ​

Flat objects with primitive string values are the easiest win: JSON pays for braces and quoted keys and strings, while TOON drops braces at the root, omits quotes on simple keys, and uses one line per field.

For objects with only string primitives:

If all values are strings that can be unquoted in TOON, this simplifies to:

Example: For 1,000,000 objects, TOON saves 3,000,002 bytes ≈ 2.86 MB.

Empirical Validation ​

{ "id": 1, "name": "Ada" }

Nested Objects ​

Adding a wrapper object (one extra level of nesting) introduces extra braces for JSON and extra indentation and newlines for TOON. For a single level of nesting with primitive values, TOON still comes out ahead, but the net advantage is smaller.

For a single level of nesting with primitives:

Example: For 1,000,000 nested objects (depth 1), TOON saves 1,000,005 bytes ≈ 0.95 MB.

Empirical Validation ​

{ "user": { "id": 1, "name": "Ada" } }

user:
  id: 1
  name: Ada

Primitive Arrays ​

For arrays of string primitives, JSON writes ["foo","bar","baz"], quoting every string and using [] for the array. TOON writes key[N]: foo,bar,baz, paying once for the length marker but omitting most quotes.

For arrays of $n$ string primitives:

With string values that can be unquoted in TOON, this simplifies to:

Example: For 1,000,000 elements, TOON saves 1,999,996 bytes ≈ 1.91 MB.

Empirical Validation ​

{ "tags": ["foo", "bar", "baz"] }

Root Arrays ​

At the root, JSON writes ["x","y","z"]; TOON writes [3]: x,y,z. There is no object key cost, so the advantage mainly comes from not quoting TOON-safe strings and from replacing [] with [N]:.

For root-level arrays of $n$ string primitives:

Example: For 1,000,000 elements, TOON saves 1,999,991 bytes ≈ 1.91 MB.

Empirical Validation ​

Tabular Arrays ​

Uniform arrays of objects are TOON's sweet spot. JSON repeats every key for every row, while TOON declares the length and column names once (key[N]{id,qty,...}:) and streams rows as bare values.

For arrays of objects with $n$ rows and $m$ fields, assuming numeric values and $|k|=3$:

Example: For 1,000,000 rows with 2 fields and 3-character field names, TOON saves 11,999,987 bytes ≈ 11.44 MB.

This is where TOON's design (declare fields once, stream rows) pays off most strongly: savings grow linearly with both row count and field count.

Empirical Validation ​

{ "items": [{ "id": 1, "qty": 5 }, { "id": 2, "qty": 3 }] }

items[2]{id,qty}:
  1,5
  2,3

Arrays of Arrays ​

Arrays of arrays of primitives are where TOON structurally loses: each inner array becomes a list item with its own header, so TOON pays a fixed overhead per inner array ("- " plus "[m]: "), while JSON just uses commas.

For arrays of arrays with $n$ outer elements and $m$ inner elements:

With string primitives and $m=2$:

Example: For 1,000,000 arrays with $m=2$, TOON wastes 2,999,998 bytes ≈ 2.86 MB relative to JSON under this model.

Empirical Validation ​

{ "pairs": [[1, 2], [3, 4]] }

pairs[2]:
  - [2]: 1,2
  - [2]: 3,4

Strings That Look Like Literals ​

Strings that look like numbers or booleans (e.g. "123", "true") must be quoted in both JSON and TOON, slightly reducing TOON's advantage because it no longer saves quotes on those values.

For objects containing such strings:

Example: For 1,000,000 objects, TOON saves 2,000,002 bytes ≈ 1.91 MB.

Empirical Validation ​

{ "version": "123", "enabled": "true" }

version: "123"
enabled: "true"

Empty Structures ​

Empty containers reveal structural differences even at minimal sizes.

Empty Object:

JSON requires {} (2 bytes), whereas a completely empty root object in TOON is represented as an empty document (0 bytes).

Empty Array (field):

For a field named key, JSON uses {"key":[]} in compact form, while TOON uses:

Under this model, that yields a constant 3-byte advantage for TOON.

Summary Table ​

The table below summarizes the formulas and which side wins under the modeling assumptions.

In short:

• TOON's gains are linear in the number of fields for flat objects.
• For arrays, gains grow linearly in the number of elements, and for tabular arrays linearly in both rows and fields.
• Arrays of arrays are the main structural case where JSON is smaller.
• Deep nesting and heavy quoting can erode or reverse these advantages in real data.

Conclusion ​

This simplified theoretical model supports TOON's design goal: structurally, it reduces overhead compared to compact JSON in many common patterns by:

• avoiding repeated keys in tabular arrays,
• omitting quotes on many keys and values,
• and replacing braces with indentation at shallow depths.

For the structure families examined here and under the stated assumptions, the structural overhead of TOON is lower than that of compact JSON except for arrays of arrays. Since UTF-8 byte length is a reasonable first-order proxy for tokens, these structural savings usually translate into lower token counts in those patterns.

At the same time, this is deliberately a simplified model. In real datasets, additional factors – deeper or irregular nesting, heavily quoted strings, exponent notation in JSON, and tokenizer idiosyncrasies – can reduce or even reverse these gains. Our Benchmarks and When Not to Use TOON show that compact JSON can be more efficient for deeply nested or low-tabularity data. Use this page as intuition for why TOON behaves the way it does, not as a universal guarantee.

• Benchmarks – Empirical token count and accuracy comparisons across formats
• Specification – Formal TOON specification

References ​

This analysis is based on:

• Original Research: TOON vs. JSON: A Mathematical Evaluation of Byte Efficiency in Structured Data
• TOON Specification: toon-format/spec
• JSON Specification: RFC 8259, ECMA-404

This page was contributed by Mateo Lafalce (@mateolafalce).

Have questions or found an error in the formalization? Open an issue on GitHub or contribute improvements to this analysis.