JSON to YAML
Convert JSON into readable YAML for Kubernetes manifests, CI files and config.
JSON to YAML tool
What this tool does
YAML 1.2 is a superset of JSON, so every valid JSON document is already valid YAML — but
nobody wants to read braces and quotes in a Kubernetes manifest. This converter rewrites the
document in YAML's block style: nesting becomes indentation, arrays become
- items, and quotes disappear from every string that does not need them.
You choose the indent width, whether keys are sorted, how aggressively strings are quoted, and
whether a top-level array is emitted as one document per element — the form
kubectl apply -f expects from a file holding several manifests. The Swap button
sends the result back through the other way, so you can check the round trip immediately.
Common uses
-
Converting a JSON manifest exported by
kubectl get -o jsonback into the YAML you keep in Git. - Rewriting a generated JSON config as a GitHub Actions workflow or a Docker Compose file.
- Producing a readable, commentable version of settings your tooling emits as JSON.
- Sorting keys so two large configs can be diffed without field order getting in the way.
- Pasting a nested value into a Helm
values.yamlat the right indentation.
A short example
This JSON:
{"jobs":{"test":{"runs-on":"ubuntu-latest","steps":[{"uses":"actions/checkout@v4"},{"run":"npm test"}]}}}becomes:
jobs:
test:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v4
- run: npm testWhich strings end up quoted, and why
A YAML scalar is only quoted when leaving it bare would change its meaning, which is why the
output looks inconsistent at first glance. The converter quotes a string when it would
otherwise be read as another type — 'true', 'null',
'42', '1.0' — or when it starts with a character that has structural
meaning: { [ & * # ! | > % @, a leading or
trailing space, or an embedded : . Anything else stays bare.
This matters for version numbers in particular. version: 1.10 is the number
1.1 in every YAML parser; version: '1.10' is the string you meant. Since the
input here is JSON, the type is already unambiguous and the quoting is chosen to preserve it.
Worth knowing
Three things do not survive the conversion, because JSON has no way to express them. Comments
are lost — JSON has none to carry, so a round trip through JSON strips every
# line from your original file. Anchors and aliases are not emitted: JSON cannot
represent a shared reference, so two identical sub-objects are written out twice rather than
as &anchor and *alias. And key order is preserved exactly as it
appears in the JSON unless you tick Sort keys — YAML mappings are formally unordered, and some
tools will reorder them again on their own.
Frequently asked questions
My workflow converted with an unquoted on key. Is that safe?
GitHub’s own parser copes, but the output follows YAML 1.2, where on, off, yes and no are ordinary strings and are therefore left bare. A YAML 1.1 reader — PyYAML, Go’s yaml.v2, several linters — takes that key as the boolean true, so a script looking up on finds nothing. Quote it by hand when a 1.1 tool consumes the file.
How is a string containing newlines written out?
As a literal block scalar, which keeps it readable instead of filling the line with escapes. A value that ends in a newline is emitted as |, and one that does not as |-, where the dash is a chomping indicator telling the parser not to add the final break back. That single character decides whether an embedded script or a PEM body round-trips byte for byte.
Should list items be indented under their key?
Both forms are legal — a sequence may begin at its parent key’s column or one level in — and kubectl, Helm and Docker Compose accept either. The output here indents them, as most emitters do. If your repository runs yamllint, the indent-sequences setting of its indentation rule is what decides which form it demands; consistent accepts whichever the file already uses.