JSON and YAML Converter
Two-way conversion between JSON and YAML: the YAML output uses 2-space indentation and keeps key order, and YAML input comes back as formatted JSON.
Kubernetes manifests and CI workflows are written in YAML, while APIs and application config usually hand you JSON. Editing one against the other invites broken indentation and strings that quietly become numbers. This page converts both ways: JSON to YAML gives you indented output you can commit, and YAML to JSON gives you formatted JSON that programs can read.
The conversion is done by js-yaml in the browser, so configuration content never leaves the machine and manifests containing secrets are safe to paste. What is not safe is the assumption that every value survives: YAML infers scalar types, so an unquoted 007 becomes the number 7, comments have no JSON equivalent, and a multi-document stream is rejected outright. The sections below list what is lost and how to avoid it.
How each direction behaves
JSON to YAML serializes with js-yaml: indentation is fixed at 2 spaces, lines are not wrapped, and keys keep the order they had in the JSON. YAML to JSON loads the document into an object and prints it with a 2-space indent. Comments in the YAML are dropped, because JSON has no comment syntax. Anchors and aliases are resolved while loading, so the data is written out in full and the reference relationship disappears; a merge key written as << is not resolved at all and simply becomes a key named <<. js-yaml also rejects input rather than guessing: duplicate keys, tabs used for indentation, and streams containing more than one document separated by --- all raise an error, and an empty or comments-only document has nothing to convert.
Scalar inference: leading zeros and precision
A YAML scalar takes its type from how it is written. Reading 010 and 007 gives the numbers 10 and 7, so the leading zeros are gone before any conversion happens; a value such as 3.141592653589793238 is rounded to double precision, and an integer with more than about 15 significant digits becomes an approximation. true, false and null become JSON booleans and null when unquoted, and stay strings when quoted. The fix is always the same: quote the value in the YAML, as in zip: "010", which also makes js-yaml quote it again on the way out so the string survives a round trip.
Numbers, key order and comments in the JSON direction
The JSON to YAML side normalizes numbers too, because they are parsed before serialization: 1.0 becomes 1 and 1e3 becomes 1000, and neither original spelling can be recovered afterwards. Key order is preserved for ordinary keys, but JavaScript objects list integer-like keys first in ascending order, so a map whose keys are all numbers — HTTP status codes or error codes, for instance — comes out sorted rather than in the order you wrote it. That matters when you diff two YAML files. JSON has no comments, so the generated YAML has none either; add the # lines by hand after converting.
Frequently asked questions
- Are comments and anchors preserved when converting YAML to JSON?
- Comments are not, because JSON has no syntax for them, and the reverse direction cannot invent them. Anchors and aliases become plain values, with the data written out in full. A merge key (<<) is not resolved by js-yaml at all: it stays as a literal key named <<, so a config that relies on merges should be expanded by hand or with another tool before converting.
- Why did leading zeros disappear, and why did the decimals change?
- YAML infers types from how a scalar is written, and that happens while the document is being read. 010 is parsed as the number 10, and long decimals are limited by double-precision floats. Quote the value if it is an identifier rather than a quantity: a quoted "007" stays a string, and the YAML output quotes it again so it survives a round trip.
- Can I convert a file with multiple YAML documents?
- Not in one pass. The converter loads a single document and raises an error when it finds a second --- separator. Split the stream and convert each document separately, or merge the documents into one array on the JSON side if the schema allows it.
- What indentation does the YAML output use, and can I change it?
- Two spaces, fixed — the default of the serializer and the convention used by Kubernetes, Ansible and GitHub Actions, so the output can be committed directly. There is no option for 4 spaces or for line wrapping; reformat the file with your own tooling if your project requires a different style.