YAML is the format of choice for Docker, Kubernetes and many config files, and converting JSON to it by hand invites mistakes. This tool does it for you, quoting values that would otherwise be misread (the text yes, null, anything that looks like a number) and writing empty lists and objects correctly.
How to use it
- Paste your JSON.
- Read the YAML.
- Check any quoted strings.
- Copy it into your configuration file.
When it helps
- Writing config files from JSON samples.
- Converting API output for documentation.
- Seeing the differences between the formats.
- Moving settings between tools.
Good to know
- Strings that look like numbers or booleans are quoted so they keep their type.
- Indentation is two spaces, the YAML convention.
- YAML parsers differ slightly, so test the result in your own tool.
How the conversion works
Objects become key-value lines, arrays become lists with dashes, and nesting is shown by two-space indentation. The converter quotes anything that could be misread: the strings true, yes and null, numeric-looking strings, text with colons or leading symbols, and empty strings.
Multi-line strings are kept as quoted strings with escapes.
Worked example: a config
A JSON object with a name, version, tags and nested owner becomes five lines of YAML, with tags as a dash list. Paste it into a file such as config.yaml. Check that numbers you meant as text, like a version 1.10, are quoted so they stay text.
Empty arrays and objects become [] and {}.
YAML pitfalls
YAML is whitespace sensitive, so mixing tabs and spaces causes errors. Unquoted values like no, on and off can be read as booleans, the so-called Norway problem, where the country code NO becomes false. The converter quotes those for you.
Always validate the YAML with the tool that will read it.
When to choose which format
JSON is stricter, universal in APIs and easy for programs. YAML is easier for people to read and allows comments, which is why configuration for Docker, Kubernetes and CI services uses it.
If you need comments, YAML wins. If you need reliability across tools, JSON wins.
Validating the YAML
After converting, run the YAML through the tool that will read it, such as a linter or your application's config loader. Look out for indentation errors and values that changed type. If you have a schema, validate against it.
Add comments in YAML to explain settings, which JSON can't do.
Keeping a JSON copy
Keep your original JSON next to the converted YAML while you test. If something behaves differently, compare the two to see which value changed. Tools exist for converting back, so you can check the round trip.
Questions
Is YAML a superset of JSON?
Mostly; valid JSON is nearly always valid YAML.
Can it convert YAML back?
No, this goes one way.