piapia123
en

TOON ↔ JSON

Format

Everything runs locally in your browser — nothing is uploaded

Input
Drop a file here to load its contents
Output

TOON (Token-Oriented Object Notation) is a compact form aimed at LLM prompts: a set of identically shaped objects is written as one table, the keys appear once in the header, and the rows are all data. ``` users[2]{id,name,role}: 1,Alice,admin 2,Bob,user ``` The same data in JSON is `[{"id":1,"name":"Alice","role":"admin"},…]` — every object repeats all three keys. That repetition, plus the braces and quotes, is what TOON removes. ⚠️ These are character counts, not token counts. Saving tokens is TOON’s whole selling point, so that is the number you most want — but it cannot be counted accurately here: it depends on the tokenizer (GPT, Claude and the open BPE variants all differ, and Chinese text and code are split differently again). Getting it right means shipping a 1–2 MB tokenizer, and that would only give the answer for one tokenizer, which would then be read as a general result. So this gives the part that can be counted exactly. ⚠️ Saving 40% of the characters is not saving 40% of the tokens. ⚠️ The JSON side of the comparison is compact (no indentation): what TOON saves is mainly key names and braces, and indentation hides exactly that — comparing against indented JSON makes it look as though TOON saves almost nothing.

Features

  • Both directions: JSON → TOON and TOON → JSON, or pick one explicitly
  • Three delimiters: comma, tab (the most compact) and pipe
  • ⚠️ A character count comparison with the percentage change; a negative number means TOON is shorter
  • ⚠️ Says plainly that these are characters rather than tokens, and why the token count cannot be given
  • ⚠️ The JSON side is measured compact, so indentation does not mislead the comparison
  • Handles key-value pairs, nested objects, arrays and tabular arrays
  • ⚠️ On failure, names the two things that actually fail: a table whose row count disagrees with its declared size, and an unterminated quote
  • ⚠️ Notes that “it produced output” does not mean “it read it correctly” — the TOON decoder is quite forgiving
  • Runs entirely in your browser

How to use

  1. Paste JSON or TOON; the direction is detected
  2. Switch the delimiter for table-heavy data — tab saves the most characters
  3. Read the result and the character comparison; if you are feeding a model, the percentage line is the one that matters

FAQ

Why give character counts and not token counts?
Because it cannot be counted accurately, and a confident wrong number is worse than none. Token counts depend on the tokenizer: GPT’s cl100k and o200k, Claude’s, and the various open BPE implementations all split differently, and Chinese text, code and JSON diverge even more between them. Doing it properly means shipping a 1–2 MB tokenizer in the page, and that would still only give the answer for one tokenizer while being read as general. So this gives what can be counted exactly: characters. Character count correlates strongly with token count (what TOON removes is mostly repeated keys and braces), but “40% fewer characters” is not “40% fewer tokens”.
Where does TOON actually save?
Two places. Repeated key names: for a set of identically shaped objects, JSON writes `"id"`, `"name"` and `"role"` in every one, while TOON writes them once in the header and the rows are pure data. Braces and quotes: `{}`, `[]` and `""` add up across a large array. So the more regular the data, the more it saves — a table of dozens of rows with identical fields can halve the size, while an object with three keys and no arrays is about the same length, or longer.
Why does a table carry a `[2]`?
That is the row count, and TOON uses it to confirm the table is complete. It is not decoration — the decoder compares it against the rows it actually read and raises an error when they disagree (“Expected 3 tabular rows, but got 1”). It is easy to forget when editing TOON by hand: delete a row without updating the number and the next read fails. This is one of the few things the decoder genuinely rejects.
What does “produced output” not meaning “read correctly” mean?
The TOON decoder is quite forgiving. In testing it raises errors for exactly two things: a table whose row count disagrees with its declared size, and an unterminated quote. Beyond that, a line of complete nonsense is read as a string — you get a “successful” result whose content is not what you thought. So when pasting TOON in from elsewhere, glance at the resulting JSON rather than just checking for an error.
When should I use TOON?
When putting structured data into a prompt. It is shorter than JSON, and because the tables line up row by row it reads well for a model too. Not for: moving data between machines (that is JSON’s territory, where every language has a stable parser), anything needing a strict specification (TOON is young; the reference implementation is the specification), or config files people edit by hand (the `[N]` count is easy to forget and nothing will warn you).

Related tools