JSON to TOML: Differences, Edge Cases & Pitfalls

Convert JSON into TOML configuration, with sections for arrays of objects and native date-time output.

TOML is a configuration format rather than an interchange one, and it has rules of its own: the root must be a table, arrays of objects become repeated sections, and dates are a native type. A JSON round trip through TOML usually returns with different date and comment semantics.

Format Differences

AspectJSONTOML
Designed forData interchangeConfiguration files
CommentsNot supportedSupported with #
Date typeNo native type; string conventionNative RFC 3339 date-times
NestingBraces nest directlyDotted headers and [table] sections; verbose when deep
ArraysNative, heterogeneous nesting allowedGood for homogeneous arrays; arrays of objects need repeated [[key]]
Top levelMay be an array or scalarMust be a table (key-value collection)
ReadabilityExplicit structure, good for programsExcellent for flat config, poor for deep data
SpecRFC 8259 / ECMA-404TOML v1.0.0 (stable since 1.0)

Edge Cases

  • A JSON array at the top level cannot convert directly (TOML requires a table root) — wrap it in a key or pick another format.
  • Keys containing dots parse as nested tables; quote the whole key if it is literally "a.b".
  • An empty object {} has no direct TOML representation and is usually emitted as an empty table or dropped; verify consumer behaviour.
  • Homogeneous arrays inline cleanly, but mixed-type arrays are not allowed in TOML.

Common Pitfalls

  • Feeding a top-level JSON array makes the conversion fail and looks like the tool cannot handle arrays.
  • Dotted keys split into nested tables and every configuration lookup path breaks.
  • Date strings become native dates and normalise on the way back (timezone or precision changes).
  • Forcing deeply nested data into TOML emits dozens of [a.b.c.d] sections, less readable than the JSON you started with.

Related Tools