toolready. JSON ↔ YAML ↔ TOML

JSON ↔ YAML ↔ TOML

Trilingual config converter: JSON, YAML, and TOML.

→

What this does

Six conversions in one box: pick any of JSON, YAML and TOML as the source and any as the target. The source is parsed into an ordinary in-memory value and re-serialised into the target — js-yaml for YAML, @iarna/toml for TOML, the browser's own JSON.parse for JSON. The pipeline is data-first, not text-first, so anything a data model can't hold is dropped along the way. All three libraries load into your browser on demand; the document you paste is never transmitted.

How do I convert a config file between formats?

  1. Set From to the format you have and To to the one you want. It opens on JSON → YAML with a sample loaded.
  2. Paste the file. Output regenerates on every keystroke; parse errors show at the bottom right instead of output.
  3. Copy grabs the result; Clear resets both.
{ "name": "toolready", "version": "1.0.0", "features": ["fast", "private"] }

→ YAML                        → TOML

name: toolready               name = "toolready"
version: 1.0.0                version = "1.0.0"
features:                     features = [ "fast", "private" ]
  - fast
  - private

Which of the three should a project use?

JSON if a machine writes it and a machine reads it — no comments, every key quoted, trailing commas illegal, but supported everywhere with zero ambiguity. YAML when humans maintain deep nesting and want comments and anchors: Kubernetes manifests, GitHub Actions, Docker Compose. TOML when the file is flat-ish settings a human edits and misreading a value would be expensive — Cargo, pyproject.toml, Netlify. TOML has far fewer implicit-typing traps than YAML, at the cost of getting awkward past three levels deep.

What can TOML not represent?

Three things bite in practice. There is no null, and null values are silently dropped rather than flagged — {"a": null, "b": 1} converts to just b = 1, so check your key count. Arrays must be homogeneous: [1, "x"] is rejected in both directions with Array values can't have mixed types. And the document root must be a table, so a top-level JSON array raises TOML requires a top-level object (table) — wrap it as {"items": [...]} first. Key order also shifts, because plain values are hoisted above the [section] headers that follow them.

What gets lost in any direction?

Comments, always. Both parsers discard # lines, so a heavily annotated config comes back bare — commit the original before you paste the output over it. YAML anchors and aliases are expanded at parse time, so &base / *base reuse becomes repeated copies. Formatting goes too: block scalars, inline versus expanded arrays, quoting style and blank-line grouping are re-derived by the serialiser, not preserved.

How are dates and big numbers handled?

Both YAML and TOML have real date types; JSON does not. An unquoted 2024-01-01 in either becomes a date value that reaches JSON as a string — a YAML date picks up a midnight-UTC time ("2024-01-01T00:00:00.000Z"), while a TOML local date stays "1979-05-27". Quote it at the source if it was meant as text. Integers beyond 253 are worse: TOML parses them as BigInt and converting to JSON fails with Do not know how to serialize a BigInt. Quote long IDs.

Which tool should I use for two formats instead of three?

For YAML and JSON alone, the dedicated YAML ↔ JSON converter suits better — side-by-side panes, an indent selector and a swap button. Use the JSON formatter to validate JSON on its own, CSV to JSON for spreadsheet exports, and JSON to TypeScript for types.