We Tested TOON for Token Efficiency, and found some useful cases

Part of what we do at The Orange Force is explore new tech before recommending it to anyone. So when my colleague Trong Tran spotted TOON as a “token-efficient alternative to JSON”, we had to take a look. Our first reaction: skeptical. Another format trying to solve a problem that JSON handles fine? Sure. But curiosity won, as it usually does around here. We built a converter and ran the numbers.

What is TOON?

**Quick explainer:** TOON (Token Oriented Object Notation) is a data format specifically designed to reduce token consumption when communicating with Large Language Models.

The name says it all: where JSON prioritizes human readability and universal compatibility, TOON prioritizes token efficiency. It strips away the structural overhead that JSON carries (curly braces, quotation marks around keys, repeated field names) while preserving the data itself.

Think of it as a middle ground between JSON and CSV. More structured than comma-separated values, but leaner than JSON’s verbose syntax.

Why we investigated this

If you’re building Mendix applications that integrate with LLM APIs (OpenAI, Anthropic, Azure OpenAI, etc.), you’re paying per token. And tokens add up fast.

Consider this example of company data you might send to an LLM for analysis:

Count the characters that carry no actual information: all those curly braces, square brackets, quotation marks around every key, and the repeated field names (“name”, “industry”, “employees”…) for each company. That’s structural overhead you’re paying for with every API call.

**Our hypothesis:** If TOON genuinely reduces token consumption, it could mean significant savings for Mendix applications with heavy LLM integration.

What we built

We kept it simple and practical. We created a Mendix Marketplace module containing a Java action that converts JSON to TOON format. Call the action, pass in your JSON string, get TOON back. That’s it.

This allows you to prepare your data in familiar JSON format within Mendix, then convert it to TOON right before sending it to an LLM endpoint.

The module is available on the Mendix Marketplace.

What does TOON look like?

Running our JSON example through the converter produces this:

Notice what’s gone: the curly braces, the quotation marks around keys, the square brackets for arrays. The data is still structured and readable, but with significantly less overhead.

The numbers: does it actually work?

We ran our tests using the OpenAI Tokenizer, which calculates exactly how many tokens a piece of text consumes. Here’s what we found:

Format	Tokens	Characters
JSON	195	652
TOON	144	486
Savings	26%	25%

A 26% token reduction on a simple three-record payload. Not bad for a straightforward conversion.

Format	Tokens	Characters
JSON	5,174	15,862
TOON	4,382	14,831
Savings	15%	6.5%

Format	Tokens	Characters
JSON	51,731	158,620
TOON	43,820	148,310
Savings	15%	6.5%

What these numbers tell us

The percentage savings decrease as datasets grow larger (from 26% to roughly 15%), but that 15% remains consistent at scale. This makes sense: JSON’s overhead is relatively fixed (braces, quotes, colons), so it has a larger proportional impact on small payloads.

But here’s the thing: at 1000 records, that 15% means almost 8,000 tokens saved per request. If you’re making hundreds of these calls daily, the absolute savings add up quickly.

The reality check

TOON has clear limitations, and we want to be upfront about them:

**It cannot do everything JSON can.** Complex nested structures, mixed data types, and self-documenting schemas are JSON’s strengths. TOON trades flexibility for compactness. For flat, repetitive data, it excels. For deeply nested objects with varying structures, you may find yourself working against the format rather than with it.

**It is essentially a simpler form of CSV.** When you strip away the marketing, TOON does what CSV has done for decades: removing redundant structure to save space. The question becomes whether TOON offers enough advantages over plain CSV to justify adopting yet another format.

**Tooling is limited.** JSON has decades of ecosystem support, parsers in every language, and debugging tools everywhere. TOON has… almost none of that. You will need to handle parsing carefully, and debugging malformed TOON is less pleasant than debugging malformed JSON.

**LLM output is another story.** When you need the LLM to return structured data, JSON remains more reliable. LLMs are extensively trained on JSON and produce it consistently. Asking for TOON output may lead to inconsistent or malformed responses.

## Let’s be clear: TOON is not replacing JSON

Almost all web communication today runs on JSON. APIs, configuration files, data exchange between services: JSON is the universal language. And for good reason. It is human-readable, self-documenting, universally supported, and battle-tested.

We do not see TOON as a replacement for JSON in these contexts. Not even close. The world does not need another competing standard.

What we do see is a specific, narrow use case: reducing costs when sending data to LLMs. That is where TOON earns its place. Not as a new universal standard, but as an optimization tool for a particular problem.

When should you consider TOON?

Here is a simple decision tree:

Decision Protocol: TOON vs JSON

---

[STEP 1] DATA FLOW

Are you sending data TO an LLM (not receiving)?

├── NO [OUTPUT] → Stick with JSON

└── YES [INPUT] → NEXT STEP…

    │

[STEP 2] COMPLEXITY

    Is your data flat and repetitive (lists of similar objects)?

    ├── NO [COMPLEX] → Stick with JSON

    └── YES [SIMPLE]→ NEXT STEP…

        │

[STEP 3] VOLUME

        Are API calls frequent (cost sensitivity)?

        ├── NO [LOW VOL] → Not worth the complexity

        └── YES [HIGH VOL] → TOON is worth testing

            │

[STEP 4] OUTPUT NEEDS

            Do you require structured return data?

            ├── YES → Use TOON (In) + JSON (Out)

            └── NO → Use TOON (Full Cycle)

**TOON works well for:**

• Bulk data transmission to LLMs (lists of similar records)
• Repetitive API calls with consistent data structures
• Cost-sensitive applications where token savings compound
• Input data only (let the LLM respond in natural language or JSON)

**Stick with JSON for:**

• Complex, deeply nested data structures
• When you need structured LLM output
• One-off or infrequent API calls
• Any non-LLM communication (APIs, config files, data storage)

Our verdict

Is TOON the future of data exchange? No. JSON is not going anywhere, and it should not.

Is TOON useful? For a specific, well-defined use case: yes. If you are building Mendix applications with significant LLM integration costs, and your data fits the “flat, repetitive, input-only” pattern, TOON can deliver real savings.

We approached this with skepticism, tested it properly, and found it genuinely useful within its limitations. That is exactly the kind of pragmatic tool we like to share with the community.

Try it yourself

The module is available on the Mendix Marketplace. Install it, run some comparisons with your own data, and see if the token savings justify the trade-offs for your specific use case.

We would love to hear what you find. Are there scenarios we missed? Edge cases where TOON breaks down? Other creative uses? Let us know. We are still learning too.

Check out the Mendix Marketplace module here!

*Questions or feedback? Reach out to The Orange Force. We are always happy to geek out about optimization strategies.