TOML ↔ JSON Converter

Features

• Both directions: TOML → JSON and JSON → TOML, detected automatically or set by hand
• All four date/time kinds handled per spec: local dates and times get no timezone shift (which would move the date by a day)
• Arrays of tables `[[x]]` and arrays of objects convert either way; dotted keys expand into nested objects; keys needing quotes get them
• Big integers via BigInt: anything past 2^53 is emitted as a string, digit for digit
• inf / -inf / nan become strings instead of quietly turning into null the way JSON.stringify does
• JSON → TOML reports nulls with their path (TOML has no null type; the default behaviour drops the key)
• Nulls can instead become an empty string or be skipped; a null inside an array cannot be skipped (it would shift every later index)
• Parse errors point at a line and column rather than saying “invalid format”
• A non-object top level is explained (“a TOML document is always a table”) instead of surfacing a library error
• Syntax-highlighted output; JSON indent of 2 or 4 spaces, or a tab

How to use

1. Paste TOML or JSON — anything that parses as JSON is treated as JSON, the rest as TOML
2. The result updates as you type; the direction can also be set by hand
3. If JSON → TOML reports a null, pick how to handle it and continue
4. Copy the result

FAQ

Why does it error on a null in my JSON?

Because TOML has no null type at all. Converting one has three possible outcomes and none is lossless: the key disappears entirely (the library’s default, and the most dangerous — you get a config quietly missing a field), the value becomes an empty string (the key survives, the type changes from null to string), or the key is skipped. This tool errors by default and names the offending key, because the other two leave you with a config that looks fine but is not, and nothing tells you. Once you know which key it is, pick one of the options to continue.

Why did big integers become strings? And inf / nan?

Because JSON cannot express them. Integers beyond 2^53 have no exact representation in JavaScript — `9223372036854775807` becomes `...5808`, with the trailing digits quietly lost. And `inf` / `-inf` / `nan` have no representation whatsoever: `JSON.stringify(Infinity)` produces null, with no error. Rather than emit a value that looks right but is not, these become strings — the type changes, the value does not, and you can see the change in the output.

Why do local dates have no timezone?

Because they have none in TOML. `birthday = 1979-05-27` means *that day*, and `alarm = 07:32:00` means *that time of day*; neither points at an instant. If the conversion treated it as “1979-05-27 00:00 UTC” and then rendered it in your timezone, anyone east of UTC would see 26 May — the date shifted by a day. So the output keeps `1979-05-27` exactly, with no `Z`. The two offset forms (`1979-05-27T07:32:00Z`, `...-07:00`) keep their offset.

Where did the comments go?

JSON has no structure that can carry a comment — it has objects, arrays and scalars only. Converting to JSON can therefore only discard them, and the reverse direction has none to preserve in the first place. If the comments matter, keep the original TOML around rather than treating it as an intermediate step.