How this tool measures, and what it cannot

A number is only worth quoting if you can see how it was produced. Here is the whole method, including the parts that weaken the claims.

Every figure on this site is produced by the same code that runs the converter, at build time, from payloads you can load and check. This page states the method so the numbers can be checked rather than believed.

Where the work happens

In your browser. The page is static HTML; the converter is a JavaScript island that hydrates in the tab. The JSON you paste is parsed, encoded, tokenized and analysed locally — it is never sent anywhere, because there is nowhere for it to be sent. The server has no endpoint that accepts it.

That is a privacy property, and it is also why the tool works on payloads you would not paste into a hosted service. The one thing the site does measure is which pages get read — with self-hosted, cookie-free software on the same server, which never sees the converter’s contents.

The encoder

@toon-format/toon version 4.1 — the reference implementation of the TOON specification, not a reimplementation. This matters more than it sounds: the specification has edge cases around quoting, delimiters inside values, Unicode and numeric formats where a hand-written encoder produces output that looks right and does not round-trip.

The wrapper around it is verified with a property test: for randomly generated JSON values, decode(encode(x)) must equal x. That test found one real result worth stating — -0 comes back as +0. It is not a defect. JSON.stringify(-0) produces "0", so JSON loses the sign too, and TOON encodes the JSON data model rather than JavaScript’s.

The tokenizer

For OpenAI models the counts are exact, computed in the browser with the real encodings: o200k_base for GPT-4o, GPT-4.1 and GPT-5, cl100k_base for the GPT-3.5 generation.

For Claude and Gemini they are estimates, and the interface says so on every screen that shows one. Anthropic does not publish an offline tokenizer — counting is only available through its /v1/messages/count_tokens endpoint — and Google’s is likewise not available as a local library. The estimate scales an OpenAI count by a fixed factor, and that factor has not yet been calibrated against the vendors’ own endpoints. Treat those two as a direction, not a budget.

This is the one place where the site publishes a number it cannot fully stand behind, which is exactly why it is labelled rather than blended in.

The baseline

Minified JSON: JSON.stringify(data) with no second argument.

Most published TOON comparisons use indented JSON instead. That inflates every saving by roughly 30 percentage points and describes a scenario that does not exist — no serialiser emits indentation by default, and nobody pays to send whitespace to a model.

CSV appears in the comparison only when it would be lossless, meaning the payload is the record array. For {status, page, data: [...]} a CSV of the data array silently drops status and page, so presenting it as the cheapest option would compare two different payloads.

Payload	TOON	JSON	CSV	Difference	Cheapest
API response	210	353	—	−41%	TOON
Plain table	195	338	163	−42%	CSV
Nested config	81	67	—	+21%	JSON
Records with a list	290	218	—	+33%	JSON

Token counts from OpenAI’s o200k_base tokenizer, measured at build time. JSON means minified JSON — the baseline that actually goes into a prompt. Each payload is loadable in the converter under the same name.

What the numbers exclude

Prompt overhead. No figure here includes the tokens spent explaining TOON’s syntax to the model. That is a fixed cost per call — roughly 80–120 tokens for a short explanation with one worked example — and on small payloads it exceeds the entire saving. The cost calculator in the tool states this beneath its result rather than in a footnote.

Output tokens. Everything measured is input. If you ask the model to reply in JSON, which you should, the response side is unchanged.

Accuracy. This tool measures tokens, not whether a model reads TOON as well as JSON. Published benchmarks put the two within a point or two of each other, but that varies by model and task, and smaller models are the more likely to struggle with a less familiar format. If you are optimising a pipeline on a small model, evaluate accuracy on your own task.

How the verdict is decided

The analyzer classifies the payload, counts every format, and then applies three rules that a raw percentage cannot express:

A tiny payload is never a clear win. Four tokens against five is “20% saved” and means nothing next to per-call prompt overhead.
If CSV is cheaper, TOON is not the winner — even when TOON still beats JSON. The honest answer names the cheaper option.
A uniform array inside a wrapper is not “deeply nested”, even though it measures four levels deep. It is precisely TOON’s good case, and labelling it by depth would contradict the measurement sitting next to it.

Those three rules exist because the first version of the analyzer got all three cases wrong while passing its unit tests. The numbers were right; the conclusions drawn from them were not.

Reproducing it

Load any sample in the converter and the figures appear. Or run the comparison yourself: minify your JSON, encode it as TOON, count both with your model’s tokenizer, and subtract what your prompt spends on explanation. The fourth step is the one most comparisons skip.

The machine-readable version of everything above, with the full measurement table, is at /llms-full.txt.