Lintify Logo
Lintify
Converters

JSON to YAML Converter

Convert JSON to clean, readable YAML. Great for Kubernetes manifests, CI configs, and any tool that prefers YAML over JSON.

JSON input
1
YAML
Output will appear here…

Convert JSON to clean, readable YAML

YAML is JSON's friendlier cousin. It supports the same data model — objects, arrays, strings, numbers, booleans, null — but uses indentation instead of braces and brackets, which makes config files much easier to read at a glance. YAML is the standard format for Kubernetes manifests, Ansible playbooks, GitHub Actions workflows, and many CI/CD pipelines. Converting JSON to YAML lets you take a config file from an API and turn it into something a human can edit comfortably.

The converter uses js-yaml, the same library that powers Webpack, Eleventy, and most JavaScript-based YAML tooling. It preserves key order, handles nested objects and arrays correctly, and quotes strings only when necessary to preserve the original value (for example, the string yes would be quoted because YAML would otherwise parse it as a boolean).

YAML is a superset of JSON

Every valid JSON document is also a valid YAML document, because YAML supports JSON's brace-and-bracket syntax inline. The reverse is not true — YAML has many features that JSON does not have (anchors, aliases, multi-line strings, tags, multi-document files). This means converting from JSON to YAML is always safe, but converting from YAML to JSON can lose information if you used YAML-only features.

When to use YAML, when to stick with JSON

Use YAML for human-authored config files. The indentation makes long files readable, and the comment syntax lets you explain non-obvious choices. Use JSON for machine-generated config and for any data that crosses a process boundary — JSON is faster to parse, has a smaller standard library surface, and does not have YAML's footguns (like the boolean-coercion rules that turn yes intotrue).

Indentation in YAML

YAML is strict about indentation. Two spaces per level is the universal convention — every YAML tool, every style guide, and every linter defaults to two spaces. Four spaces is supported but unusual. Tabs are forbidden by the spec for indentation, so Lintify does not expose that option. Pick two spaces unless you have a specific reason to pick four.

Frequently asked questions

Common questions about the JSON → YAML tool.

Is YAML a strict superset of JSON?
Practically yes. Every valid JSON document is also a valid YAML document, because YAML supports JSON's brace-and-bracket syntax inline. The reverse is not true — YAML has many features (anchors, multi-line strings, tags) that JSON does not have, so converting YAML back to JSON can lose information.
Why are some strings in my YAML quoted?
YAML has a long list of reserved words and special values that must be quoted to be interpreted as strings. For example, the string "yes" would be parsed as a boolean unless it is quoted. Lintify uses the js-yaml dumper, which quotes strings only when necessary to preserve the original value.
Can I control the indentation?
Yes. The default is two spaces per level, which matches the convention used by most YAML tooling. You can switch to four spaces if your team prefers it. Tabs are not allowed in YAML for indentation — the spec forbids them — so the option is not exposed.
Does the converter preserve key order?
Yes. js-yaml preserves the insertion order of keys, which matches the behavior of modern JavaScript engines. Your YAML will list keys in the same order as your JSON, which is important for diffs and for human-readable config files.
Why does my multi-line string look weird?
JSON does not have a native multi-line string type, so what you have is a single string with literal \n escape sequences. When converted to YAML, Lintify can either keep the value as a single quoted line with \n escapes or use YAML's block scalar syntax. The default keeps the single-line form for safety; use a YAML-aware editor to switch to block scalars if you prefer.

Related tools