What is TOON and why would I use it instead of JSON?

TOON (Token-Oriented Object Notation) is a text format for the same data JSON represents, designed specifically to cost fewer tokens when it's the payload you paste into an LLM prompt or receive back from one. JSON's per-value quoting, repeated braces, and repeated keys in arrays of objects are cheap for a parser but expensive in tokens, since a tokenizer often spends a full token on punctuation that carries no information. TOON replaces most of that punctuation with 2-space indentation (like YAML) and, for the common case of an array of same-shaped objects, a single header line listing the field names once followed by comma-separated value rows, so the field names aren't repeated per element the way they are in a JSON array of objects.

Does converting to TOON lose any information from the original JSON?

No, the conversion this tool performs is lossless for standard JSON values: every object key, array element, string, number, boolean, and null in your input has a corresponding representation in the TOON output, and the structure (which keys are nested under which, which arrays are uniform) is fully recoverable. What TOON does give up is JSON's self-describing punctuation: a TOON parser has to track indentation levels precisely, the way a YAML parser does, since there are no closing braces to fall back on. That's the tradeoff behind the token savings, and it's why TOON is meant for machine-to-LLM payloads rather than as a general data-interchange or config format.

How does the tabular form for arrays of objects work?

When every element of an array is an object and every element has the exact same set of keys, the array is rendered as `key[N]{field1,field2,...}:` followed by one indented line per element with just the values, comma-separated, in that field order. So `"users":[{"name":"Ada","age":30},{"name":"Grace","age":40}]` becomes `users[2]{name,age}:` followed by ` Ada,30` and ` Grace,40`, listing `name` and `age` once instead of twice. If the elements don't share the exact same key set, or if any element isn't an object, the array falls back to TOON's list form (`key[N]:` followed by `- `-prefixed entries) instead, since a CSV-style row can't represent per-element structural differences.

When does a value get wrapped in double quotes?

Only when leaving it bare would be ambiguous: if the string contains a comma, colon, bracket, brace, `#`, or a literal newline (any of which could be misread as TOON structural syntax), has leading or trailing whitespace, or would otherwise look like the literals `true`, `false`, `null`, or a number. A value like `admin` is emitted bare; a value like `a, b: c` is emitted as `"a, b: c"` with the comma and colon escaped by the surrounding quotes rather than by a backslash, and any literal double quote inside the string is doubled (`""`) rather than backslash-escaped, matching CSV-style quoting rather than JSON's backslash-escaping.

Is my JSON sent anywhere when I convert it?

No. The conversion runs entirely in your browser; nothing about your input, its shape, or its content is transmitted anywhere. That matters here specifically because TOON's main use case is preparing a real payload, an API response, a database export, a config, for a prompt, so this tool is often pointed at data you wouldn't want leaving your machine before it even reaches the LLM you're sending it to.

Can I convert TOON back to JSON?

Not with this tool; this converter only goes JSON to TOON. Round-tripping TOON back to JSON requires a TOON parser that tracks indentation the way a YAML parser does, which is a meaningfully different piece of code from an encoder. If your workflow needs the reverse direction (for example, parsing a TOON-formatted response an LLM produced back into JSON for your application), you'd need a TOON decoder library in your target language; this tool doesn't provide one.

Why does an empty array render as `key[0]:` with nothing after it?

Because TOON's `[N]` count is load-bearing: a downstream TOON parser reading `tags[0]:` knows immediately, without looking at any following lines, that `tags` is an empty array and shouldn't try to consume subsequent indented lines as its contents. Rendering it any other way, like an inline `tags[0]: ` with a dangling space, would be more ambiguous to parse.

JSON to TOON Converter - Token-Oriented Object Notation

Overview

Introduction

Every token in a prompt sent to an LLM costs money and counts against a context window, and JSON's punctuation, quotes around every string, braces around every object, repeated field names in every element of an array of records, is punctuation a tokenizer often can't compress away. TOON re-encodes the same data using indentation and a CSV-style tabular form for repetitive arrays instead, aiming to say the same thing in fewer tokens.

This tool performs that conversion entirely in the browser: paste JSON, get TOON text back, ready to paste into a prompt or store as a smaller cached payload.

What Is JSON to TOON?

TOON (Token-Oriented Object Notation) is a text serialization format for the same data model JSON represents (objects, arrays, strings, numbers, booleans, null), designed around minimizing token count when the text is going to be read by an LLM rather than parsed by a traditional program.

Structurally, it looks like a hybrid of YAML and CSV: nesting is expressed through 2-space indentation the way YAML does, but an array of same-shaped objects gets a single header line naming the fields once, followed by one comma-separated row per element, the way a CSV file would represent a table. Arrays of primitives are collapsed to a single inline line with a bracketed count.

Because indentation and the `[N]` counts carry structural meaning, TOON is markedly less forgiving of formatting mistakes than JSON is; it trades some of JSON's redundant self-description for a more compact representation.

How JSON to TOON Works

The converter parses your JSON and walks it recursively. Every object becomes `key: value` lines, one per key, indented two spaces per nesting level; a nested object's own key line ends with just `key:` and its children follow indented one level deeper.

Arrays are handled by shape: an array of only primitives becomes one inline line (`key[N]: v1,v2,v3`); an array where every element is an object with the exact same set of keys becomes the tabular form (`key[N]{field1,field2,...}:` plus one CSV-style row per element); anything else, a non-uniform array of objects, or an array mixing primitives, objects, and nested arrays, falls back to a `key[N]:` header followed by `- `-prefixed list entries, each rendered using these same rules.

Scalar values are left bare unless they'd be ambiguous: a value containing a comma, colon, bracket, brace, `#`, or newline, or one that looks like `true`/`false`/`null`/a number when it's actually meant as a literal string, gets wrapped in double quotes, with any internal double quote doubled rather than backslash-escaped. The root value, if it's an object, is emitted directly with no wrapping key; a root array is emitted the same way with the `key` part simply omitted.

When To Use JSON to TOON

Use it whenever you're about to paste a sizeable JSON payload, an API response, a database query result, a config file, into an LLM prompt and want to reduce the token cost without hand-summarizing or dropping fields.

It's especially worthwhile for arrays of same-shaped records (a list of users, orders, log entries): that's exactly the case TOON's tabular form is built for, and where the savings versus repeating JSON's `{"field":value,...}` per element are largest.

Often used alongside JSON to YAML Converter, JSON Minifier and JSON Schema Generator.

Features

Advantages

Reduces token count for the same data, which lowers prompt cost and leaves more of the context window for everything else.
The tabular form for uniform arrays of objects avoids repeating field names per element, unlike JSON.
Runs entirely client-side; your data never leaves the browser during conversion.
Deterministic and lossless for standard JSON values: the same input always converts to the same output, and no data from a well-formed JSON document is dropped.

Limitations

TOON is not a drop-in replacement for JSON as a data-interchange or config format; it depends on precise indentation the way YAML does, with none of JSON's redundant closing punctuation to help a parser recover from a formatting mistake.
This tool only converts JSON to TOON, not the reverse; consuming TOON output programmatically requires a TOON-aware decoder in your target language, which this tool doesn't provide.
The tabular form only triggers when an array's objects share the exact same key set and every field value is a primitive; arrays of objects with even slightly different shapes fall back to the more verbose list form.
Token savings depend on your data's shape: a JSON document that's already mostly short keys and few repeated structures will see smaller gains than a large array of same-shaped records.

JSON vs. TOON for an array of 100 same-shaped user records

JSON vs. TOON for an array of 100 same-shaped user records
	JSON	TOON
Field names repeated per element	Yes, once per object	No, once in the header row
Quoting	Every string quoted	Only ambiguous strings quoted
Parseable by a standard library	Yes, `JSON.parse`	No, needs a TOON-aware decoder
Best for	Data interchange, configs, storage	LLM prompt payloads

Examples

Flat object

Input

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

Output

id: 1
name: Ada
active: true

A root object is emitted directly as key: value lines with no wrapping key.

Array of uniform objects (tabular form)

Input

{"users":[{"name":"Ada","age":30},{"name":"Grace","age":40}]}

Output

users[2]{name,age}:
  Ada,30
  Grace,40

Every element has the same two keys, so the field names appear once in the header and each row is just comma-separated values.

Array of primitives

Input

{"tags":["admin","editor"]}

Output

tags[2]: admin,editor

An array of only primitives is collapsed to a single inline line with a bracketed length.

Non-uniform array falls back to list form

Input

{"items":[{"id":1,"name":"Ada"},{"id":2,"price":9.99}]}

Output

items[2]:
  - id: 1
    name: Ada
  - id: 2
    price: 9.99

The two objects don't share the same key set, so the tabular form doesn't apply and each element is rendered as a dash-prefixed list entry instead.

Best Practices & Notes

Best Practices

Reach for TOON specifically for the prompt payload itself, not for your application's internal data interchange, where JSON's universal tooling support still wins.
Favor arrays of same-shaped objects where possible in the data you're about to convert; that's where TOON's tabular form produces the largest token savings versus JSON.
If an LLM needs to produce TOON back as output, show it a worked example in the prompt first. Unlike JSON, most models haven't seen as much TOON in training and benefit from an explicit pattern to follow.
Don't assume TOON round-trips through a JSON parser; treat it as a one-way, prompt-bound encoding unless you also have a TOON decoder in your pipeline.

Developer Notes

The tabular form requires every array element to be a plain object with the exact same key set and every field value to be a JSON primitive (string, number, boolean, or null); a field holding a nested object or array forces the whole array into the list fallback, since a single CSV-style row can't represent per-element nested structure. Quoting follows CSV convention (doubled internal quotes) rather than JSON's backslash-escaping, and object/array keys themselves are emitted unquoted on the assumption they're simple identifiers; a key containing a colon or other TOON-significant character isn't separately quoted by this converter.

JSON to TOON Use Cases

Shrinking a large JSON API response before pasting it into an LLM prompt to save context window and cost.
Formatting a batch of same-shaped records (orders, log lines, search results) for an LLM to summarize or analyze.
Reducing token cost for JSON that gets sent repeatedly in similar shape across many prompts.
Producing a more human-skimmable view of an array of records than raw JSON, as a side benefit of the tabular form.

Common Mistakes

Hand-editing TOON output and breaking its indentation, which (unlike JSON) has no closing braces to make the mistake obvious.
Expecting a JSON parser to read TOON directly; it can't, since TOON isn't a JSON syntax variant.
Assuming every array of objects will use the compact tabular form; if the elements don't share an identical key set, it won't.

Tips

Check the output for `[N]:` list-form headers (rather than `[N]{...}:`) as a quick sign that an array's objects don't share a uniform shape; normalizing the source data first can shrink the token count further.
Pair with the JSON Formatter to first inspect and clean up a JSON payload before converting it to TOON.
For very large payloads, convert a representative subset first to confirm the token savings are worth adopting before switching an entire pipeline over.

JSON to TOON

Overview

Introduction

What Is JSON to TOON?

How JSON to TOON Works

When To Use JSON to TOON

Features

Advantages

Limitations

JSON vs. TOON for an array of 100 same-shaped user records

Examples

Flat object

Array of uniform objects (tabular form)

Array of primitives

Non-uniform array falls back to list form

Best Practices & Notes

Best Practices

Developer Notes

JSON to TOON Use Cases

Common Mistakes

Tips

References

Frequently Asked Questions