TOON to JSON Converter

Nothing in a TOON document records whether a value was a string or a number, because the quotes were removed on the way in. The parser decides by inspection, value by value: the bare tokens true, false and null become JSON literals, anything JavaScript's Number() accepts becomes a number, and everything else stays a string.

That rule is simple enough to run in your head, which means you can name the casualties before you see them. A postcode written 02134 arrives as the number 2134. A version field of 1.0 becomes 1. A short hash like 0x1A becomes 26, because Number() understands hexadecimal literals. 1e3 becomes 1000. A twenty-digit identifier is rounded to 12345678901234567000, since it is past the 2^53 − 1 a double holds exactly. And the word Infinity resolves to a number JSON cannot express, so it reaches your output as null.

None of this is repairable afterwards; the original text no longer exists. Protect those columns before the data becomes TOON — give identifiers a non-numeric prefix, or leave them out of the tabular encoding — and accept that ordinary text, which Number() rejects, comes back unchanged.

A header such as [3]{id|name|role|active}| declares both how many rows follow and what the fields are called. Treat the row count as a claim to check rather than a guarantee: this parser converts the rows it finds, so a header announcing five rows above two rows of data yields two records and raises nothing. When TOON came out of a model that hit its output limit mid-table, that is precisely the shape of the damage, and the header is the only surviving evidence of it.

Field counts fail quietly in both directions. A row with fewer values than the header has keys leaves the trailing keys undefined, and JSON serialisation omits undefined-valued keys entirely — so the record is missing the field rather than carrying a null for it. A row with more values than the header has keys has the surplus discarded, because the parser iterates the key list and not the value list.

Two comparisons catch nearly all of this. Check the number of records in your output against the number in the header, then check that every object has the same keys as every other. In an honest conversion they always do, since identical key sets are what made the tabular encoding legal in the first place — so any object with a short key list is a truncated row, and any missing record is a truncated table.

Rows carry no delimiter declaration, so the parser infers one for each line independently: if the line contains a pipe character anywhere, it splits on pipes; otherwise it splits on commas. For pipe-delimited data this is exactly right, and a comma inside a value causes no trouble at all.

For comma-delimited data it creates a sharp failure. One pipe anywhere in a row — in a regex, a shell snippet, an ASCII table, a name recorded as Smith|Jones — makes the whole row split on that pipe instead. The row 3,a|b,x beneath a three-field comma header parses to {"a": "3,a", "b": "b,x"}: two fields where three were promised, both holding the wrong text, and the third dropped without a word.

Because detection is per line, this can corrupt exactly one record in a file of ten thousand while every other row converts perfectly, which makes it a poor thing to discover through spot checks. If you control the encoding step, use the pipe delimiter and the ambiguity disappears. If you were handed comma-mode TOON, search the rows for pipe characters before parsing rather than after.

JSON accepts any string as a key, including one with spaces, dots, or nothing at all. TOON keys are recovered by pattern matching, and the patterns are much narrower — which turns an unremarkable key name into silent data loss.

An array header is only recognised when the array name consists of word characters: letters, digits, and underscores. line-items[1]{a|b}| is not read as a header, so the line falls through to the key-value branch and produces an object containing a key literally named line-items[1]{a. Property keys, in turn, must contain no whitespace and none of :, |, or ,; a line reading full name|Alice matches nothing, is skipped without an error, and leaves you with an empty object.

Nesting warrants the same caution. A uniform array one level under an object key round-trips cleanly, which is the case the format exists to serve. Standalone nested object blocks are the weak spot: a profile| line followed by an indented block returns with profile set to an empty string and its children hoisted into the parent as siblings. Keep anything you intend to round-trip to a top-level object with tabular arrays beneath it, rename hyphenated or dotted keys first, and use JSON directly for structures deeper than that.

Every failure described above shares one property: the output is still well-formed JSON. A schema-less validator, a linter, and JSON.parse will all happily accept a document that lost a column, rounded an identifier, or silently dropped a row. Syntax checking proves nothing here. Shape checking is the only thing that does.

A short list covers most of it. Confirm the record count against the header. Confirm every object carries the same keys. Spot-check one value from each type-sensitive column — identifiers, postcodes, version strings, phone numbers, anything zero-padded — and confirm it is still a string rather than a number. If the original JSON still exists, diff against it; if it does not, expanding the result in the JSON editor is a fast way to read the structure before it travels any further.

How paranoid to be depends on provenance. TOON your own encoder produced and you are converting straight back is low risk. TOON a language model generated is untrusted input: a hallucinated extra column, a row whose values were reordered against the header, or a table cut off at a token limit all yield JSON that parses cleanly and is wrong in a way no parser can detect. Validate that against a real schema after conversion, exactly as you would any other model output.