About the JSON to TOON Converter
TOON — Token-Oriented Object Notation — is a compact serialisation aimed at one specific problem: JSON is expensive when you are paying per token. Structural characters that cost nothing on the wire cost real money in a prompt, and repeated keys in an array of objects are the worst offender, because every field name is re-tokenised for every element.
The saving is largest exactly where LLM payloads usually are: uniform arrays of records. A hundred objects sharing the same five keys pay for those keys a hundred times in JSON. Declaring the fields once and listing values compactly removes that repetition, which is where the reduction comes from.
It is not a general JSON replacement, and treating it as one is the mistake. Use it at the boundary where you are constructing a prompt, and keep JSON everywhere else — for APIs, storage and anything a normal parser must read. Converting back is what makes it safe to adopt narrowly.
Frequently asked questions
When is TOON worth using?
When you are putting structured data into a prompt and paying by the token, particularly uniform arrays of objects where key repetition dominates. For a single small object the saving is negligible and not worth the extra step. Measure your actual payload with a tokeniser rather than assuming a percentage.
Does the model understand it without explanation?
Generally yes for capable models, since the structure is regular and largely self-describing, and a brief note about the format in the prompt removes most ambiguity. Test with your specific model and data before relying on it — a format saving tokens but causing misreads costs far more than it saves.
Is the conversion lossless?
For the JSON data model it round-trips, which is why converting back is the right way to verify. Watch the usual serialisation edge cases regardless of format: very large numbers losing precision, and the distinction between an absent key and one explicitly set to null. Round-trip your real data rather than a sample.
Should I store data in TOON?
No. It is a prompt-boundary optimisation, not a storage format. Storing it means every consumer needs a converter and you lose the enormous ecosystem of tools that read JSON. Keep JSON as the source of truth and convert at the point where token cost applies.
How much does it actually save?
Entirely dependent on shape. Uniform arrays with many repeated keys see the largest reduction; deeply nested heterogeneous structures see much less. Convert a representative payload and count tokens with the tokeniser your model actually uses, since token counts differ between models and generic character-based estimates are unreliable.
Need this managed for you, not just automated?
We're also a hands-on DevOps consultancy — Kubernetes, CI/CD, and cloud infrastructure.