Tool guide
About JSON to YAML Converter
This converter turns JSON into YAML and YAML back into JSON, so the same configuration can move between an API payload and a Kubernetes manifest, a Docker Compose file, a GitHub Actions workflow, or an OpenAPI document without retyping it.
Conversion runs as you type, key order is preserved exactly as written, and indentation can be set to 2 or 4 spaces. Syntax errors report the exact line and column.
How to convert JSON to YAML
- Paste your JSON into the input panel. The YAML result appears immediately, with no button to press.
- Use the direction button to switch to YAML to JSON, for example to feed a manifest into a script that only reads JSON.
- Choose 2 or 4 space indentation to match your repository style. Kubernetes and GitHub Actions files usually use 2.
- If the input is invalid, read the reported line and column, fix that spot, and the output refreshes on its own.
When you would use it
- Turn a JSON resource dumped by kubectl into a readable YAML manifest you can commit.
- Convert a Docker Compose service block while testing generated configuration.
- Move an OpenAPI specification between its JSON and YAML forms, since tooling on each side prefers one of them.
- Rewrite a GitHub Actions workflow fragment produced as JSON into the YAML the runner expects.
YAML rules that break conversions
YAML 1.2 is close to a superset of JSON, so valid JSON is usually valid YAML. Problems appear in the other direction, where YAML guesses types that JSON never does.
- The Norway problem: NO, no, yes, on, and off are read as booleans by YAML 1.1 parsers, so the country code NO becomes false. Quote such values.
- Leading zeros: a value like 010 may be read as an octal number instead of a string. Quote identifiers, zip codes, and part numbers.
- Version numbers: an unquoted 1.10 becomes the float 1.1 and the trailing zero disappears.
- Indentation must use spaces, never a tab, and every colon that introduces a value needs a space after it.
JSON to YAML FAQ
- Does the converter reorder my keys?
- No. Keys come out in the order you supplied, which keeps diffs small in version control.
- What happens to my comments?
- JSON has no comment syntax, so JSON to YAML cannot invent comments, and YAML to JSON discards the ones the source had. Keep the original if comments matter.
- Will the output contain anchors and aliases?
- No. Repeated structures are written out in full, so any parser can read the result without alias support.
- Is my configuration uploaded anywhere?
- No. Parsing and conversion happen in your browser using js-yaml, so nothing you paste leaves your machine or is stored by wetool.site.
- Why does a YAML value change type after conversion?
- YAML guesses types for unquoted scalars. Quote a value in the YAML source and it converts to a JSON string.
JSON compared with YAML
JSON is strict and unambiguous, which makes it a good wire format, but it has no comments and gets noisy when deeply nested. YAML reads better in review, at the cost of type guessing and indentation sensitivity. Most teams keep configuration in YAML and exchange JSON at the boundaries, which is what this two way conversion is for.
Quoting checklist before you commit
Most broken deployments caused by a conversion come from a value that lost its type. Scan the YAML output for these cases.
- Country and language codes, especially NO, and any two letter value that reads like a word.
- Numbers that are really identifiers: account numbers, padded ports, anything with a leading zero.
- Versions and image tags such as 1.10 or 3.20, which lose the trailing zero when treated as floats.