TOON to YAML

Turn TOON into readable YAML

TOON (Token-Oriented Object Notation) looks a lot like YAML at first glance: nested objects are written with indentation and key: value pairs. The difference shows up in arrays. TOON compresses uniform lists of objects into tables with a header such as hikes[3]{id,name,km}: followed by comma-separated rows, and writes short primitive arrays inline as tags[3]: a,b,c. Those constructs are what make TOON cheap in LLM prompts, but no YAML parser understands them. This converter decodes TOON with the official library and re-serializes the result as standard YAML, so every row becomes a mapping in a block sequence.

That is useful when a model generates configuration, test fixtures or seed data in TOON and you need it in a Kubernetes manifest, a GitHub Actions workflow, an Ansible inventory, a Docker Compose file or any other YAML-based tool. It is also a handy way to read dense TOON tables: the YAML view lists each field on its own line, which is easier to review in a pull request.

Validation and types

With Strict mode enabled the decoder checks every declared [N] length and every table row width before producing YAML, so a truncated model answer is reported instead of silently converted. Values keep their JSON types: numbers stay numbers, true/false stay booleans, and null stays null. On output, js-yaml quotes any string that YAML 1.1 parsers would otherwise reinterpret, such as on, no, 1e3 or ISO-like dates, so the YAML loads back to exactly the same data.

Practical tips

Comments are not part of the TOON data model, so add them to the YAML afterwards if your config needs them. Key order is preserved. If the destination expects JSON instead, use the TOON to JSON converter; for spreadsheets use TOON to CSV, and for legacy integrations use TOON to XML. To go between JSON and YAML directly, try JSON ⇄ YAML. Always validate the final file with the tool that will consume it. All processing happens locally — your prompts, keys and configuration never leave the browser.