Comparing JSON and TOON for Structured Prompts

A practical way to compare JSON and TOON for structured prompt data, including token counts, parsing, and output checks.

This note describes how to compare JSON and TOON for structured prompts. It does not assume either format uses fewer tokens or preserves task quality for every model; measure both against the workload.

JSON is commonly used to represent structured data. Other text formats can represent the same information, but their usefulness depends on the data and the model consuming it.

TOON (Token-Oriented Object Notation) is one way to represent structured records, including rows that share fields. Its usefulness depends on the data shape and the model using it.

Comparing structured formats

Repeated keys and punctuation can add tokens in some prompts, but the amount depends on the data, tokenizer, and model. Measure with representative inputs before choosing a format.

Token counts can affect context use and API cost when a provider bills by tokens. They do not alone predict latency or output quality, so compare the complete request and response using the target model.

Here’s an example. This is how we typically write data in JSON:

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

Now, here is how we would write that same data in TOON:

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

This tabular example avoids repeating the field names on each row. Actual token counts depend on the data and tokenizer, so measure with representative inputs.

Core Features of TOON

These syntax characteristics may matter when choosing a prompt format:

• Token use: Token counts depend on the input data, format, and model tokenizer. Compare formats with the same representative inputs and tokenizer; do not assume a fixed percentage saving.
• Explicit structure: Declared fields can make tabular records easier to inspect, but a model can still produce malformed output.
• Syntax: Formats use different punctuation and delimiters. Compare how the target model handles each format with your actual task.
• Indentation-based structure: The format uses whitespace to show nesting. Tokenization differs by model, so measure it with the tokenizer you plan to use.
• Tabular arrays: A field list can be followed by rows of values. Validate the model output with an application parser.

Testing a format change

A format change should be tested with the target model and application.

1. Provide the expected format: Include an example only if your application needs it, then verify the output against a parser. 2. Compare the same records: Keep the data and task fixed when comparing serialized formats. 3. Validate results: Test parse success and task quality; do not assume fewer tokens preserve behavior.

Comparing serialization formats

To evaluate a structured text format, serialize the same representative records in each format, count tokens using the tokenizer for the target model, and test whether the model follows the format reliably. Record the dataset, tokenizer, model, prompt, and parsing checks so another person can reproduce the comparison. Do not infer lower latency, cost, or unchanged output quality from token count alone.

Final Thoughts

There is no single best serialization format for every model and dataset. Choose one that your application can parse and validate, and benchmark it with representative inputs.

Resource: toon-format/toon: Token-Oriented Object Notation (TOON) — format specification and implementation.