The Same Data, Two Very Different Formats
YAML and JSON describe the same data model, maps, sequences, scalars, so converting between them is mostly mechanical. What differs is who they were designed for. JSON is unambiguous and easy for machines; YAML drops the punctuation and uses indentation instead, which makes it pleasant to hand-edit and gives it a set of failure modes JSON does not have.
This converter runs both directions with configurable indentation, and reports parse errors with the line they occurred on.
How to Convert
Each direction has its own button, so you convert deliberately rather than on every keystroke.
- Paste YAML into the left pane or JSON into the right.
- Set the indentation. Two spaces is the usual YAML convention; you can also choose tabs for the JSON side.
- Convert in the direction you need. The result appears in the opposite pane.
- Read the status line, which reports success or the parse error and its location.
- Copy either pane independently, each has its own copy control.
- Note that YAML tabs are a parse error in the YAML direction; the format forbids them for indentation.
Where the Conversion Loses Something
JSON to YAML is essentially lossless, since every JSON construct has a YAML equivalent. The other direction is not. YAML comments vanish, because JSON has nowhere to put them, and in a configuration file the comments are often the most valuable part. Anchors and aliases, which let YAML reference a block defined elsewhere, are expanded into duplicated content. Multiple documents in one stream, separated by `---`, cannot be represented in a single JSON value.
YAML also has scalar types JSON lacks: dates, explicit tags, and the notorious implicit conversions. A value written as `yes`, `on` or `off` becomes a boolean in YAML 1.1 parsers, and an unquoted `1.0` is a float rather than the string you may have meant. Version numbers and country codes are the usual casualties.
Constructs That Do Not Survive the Round Trip
What happens to each YAML feature when it becomes JSON.
| YAML feature | In JSON | Result |
|---|---|---|
| # comment | No equivalent | Discarded |
| &anchor / *alias | No equivalent | Expanded to duplicates |
| --- multiple documents | One value only | Only the first survives |
| Multi-line block scalars | String with \n | Preserved, formatting flattened |
| Unquoted dates | No date type | Becomes a string |
| yes / no / on / off | true / false | Converted to booleans |
The comment row is the one that matters in practice. Converting a documented configuration file to JSON and back leaves you with working configuration that no longer explains itself, which is why the round trip is a poor way to reformat a file you intend to keep editing by hand.
Choosing Between Them
JSON is the better choice for anything a machine writes or transmits: it is unambiguous, universally supported, and has no whitespace sensitivity to get wrong. YAML earns its place in files humans edit, CI pipelines, Kubernetes manifests, application configuration, where comments and readability are worth the extra care indentation demands.
This tool uses js-yaml, an MIT-licensed parser, and runs entirely in your browser. Nothing you paste is transmitted or stored, which matters given how often YAML configuration contains credentials. Note also that a very large document is parsed into memory in one go, so multi-megabyte files may be slow on a constrained device.