A single project routinely mixes all three config formats. Kubernetes manifests and GitHub Actions workflows are YAML, package.json and API payloads are JSON, and Cargo.toml or pyproject.toml are TOML.
This converter moves data between the three, auto-detects the input format, and reports syntax errors where they occur. You can change the indent width or sort keys alphabetically to cut diff noise, both with a single click. YAML anchors and aliases are expanded during conversion, and nesting depth is unlimited.
How to use
- Paste the source — Drop your configuration into the left pane. Format detection is automatic and the result is shown as a badge below the input; override it from the dropdown if the guess is wrong.
- Pick the target format — Choose JSON, YAML or TOML. Conversion recalculates on every keystroke so you can edit the source and watch the output follow.
- Adjust indent and ordering — Setting indent to
minminifies JSON to a single line. Sort keys reorders every object alphabetically, which removes ordering noise when you compare two config files. - Copy or download — The swap button moves the output back into the input and reverses direction — a quick way to check that a round-trip preserves your data.
Frequently asked questions
My YAML comments disappear after conversion.
JSON has no comment syntax, so preserving them is structurally impossible.
Comments are also lost on a YAML-to-YAML round trip: the parser reads the document into a data structure and re-serialises it, and comments are not data. If you need to keep them, edit the original file directly and use this tool only for validation and preview.
Converting to TOML gives an error.
TOML can express less than the other two formats.
Its root must be a table, so documents that start with an array or a scalar cannot be represented. There is no TOML equivalent of null, and arrays with mixed types are not valid in the specification. Remove or stringify those values and try again.
`NODE_VERSION: 20` becomes a number instead of a string.
YAML infers types for unquoted scalars. 20 is an integer, true, no and on are booleans, and null or ~ is null.
Quote it — NODE_VERSION: "20" — to keep it a string. These inference rules cause real incidents: the Norwegian country code NO being read as boolean false is the famous example, and version: 1.10 collapsing to the number 1.1 is a close second. Always quote values whose meaning is textual: versions, codes, identifiers.
Concepts worth knowing
Three formats, three design goals
JSON was designed for machine-to-machine exchange: simple grammar, fast parsers. The cost is no comments and a verbose feel when humans write it by hand.
YAML optimises for human authoring with indentation-based structure, comments and multi-line strings — at the price of a complex grammar and type-inference pitfalls. TOML sits in between, aimed squarely at configuration files, with explicit types and flat sections that eliminate ambiguity. It fits deeply nested data poorly.
YAML indentation rules
YAML does not accept tab characters for indentation. If your editor inserts tabs, parsing fails. Items at the same level must be indented by exactly the same amount.
The - of a list item may or may not count as part of the indentation, so both styles are valid and both appear in the wild. The output here is regenerated with one consistent rule, so converting a file with inconsistent indentation is a quick way to normalise it.
Anchors and aliases
YAML lets you mark a node with &name and reuse it with *name. Combined with the merge key <<: *defaults, this removes a lot of duplication from Docker Compose and CI configuration.
Neither JSON nor TOML has an equivalent, so conversion expands every reference and the actual values repeat. If your output is longer than the input, that is why — the data itself is unchanged.