YAML to JSON Converter
YAML is a superset of JSON, so every JSON document is already valid YAML. The reverse is not true, and the gap is where CI pipelines break. This converter goes both ways and explains which YAML features have no JSON equivalent.
How to use it
- Choose YAML to JSON or JSON to YAML.
- Drop in a .yaml, .yml, or .json file. Parsing runs locally.
- Download the converted document.
The Norway problem and other implicit typing traps
YAML 1.1 resolves a set of unquoted scalars to booleans: y, yes, on, true, and their negatives n, no, off, false. This is why a country list containing NO for Norway historically parsed as the boolean false. YAML 1.2 narrowed this to just true and false, but plenty of parsers still implement 1.1 semantics, and the two disagree silently.
The same class of problem affects version numbers. An unquoted 1.10 is the float 1.1, and the trailing zero is gone. An unquoted 08 is invalid in some parsers because it looks like a malformed octal. Quoting any scalar whose meaning depends on being text is the only reliable defence.
What is lost converting YAML to JSON
JSON has no syntax for several things YAML expresses natively, so the conversion is one-way for these features.
Expect the following to disappear:
- Comments. YAML comments are not part of the data model, so they cannot be represented in JSON. If the comments document why a value is set, copy them somewhere before converting.
- Anchors and aliases. An anchor defined with &base and referenced with *base is expanded during parsing. The JSON output contains the fully resolved copies, so shared structure becomes duplicated structure and the file grows.
- Multi-document streams. A YAML file can hold several documents separated by ---, which is normal for Kubernetes manifests. JSON has no equivalent, so only the first document is converted. Split the stream first if you need all of them.
- Key ordering guarantees and block scalar styles. The literal and folded block forms both become ordinary JSON strings with the newlines baked in.
Converting JSON back to YAML
The reverse direction is mechanically safe because JSON uses a strict subset of the YAML data model. What you get is a readable block-style document with two-space indentation. It will not reconstruct the anchors, comments, or document splits from an original YAML file, because that information never survived the first conversion.
One practical note: strings that would be ambiguous when re-read, such as yes or 1.10, are emitted with quotes so that the YAML you get back parses to the same values it started with.
At a glance
| Accepted input | .yaml, .yml, .json |
|---|---|
| YAML version | 1.2 core schema |
| Multi-document | First document only |
| Output style | Block style, two-space indent |
Frequently asked questions
Why did my Kubernetes manifest only partially convert?
Manifests are usually multi-document YAML streams separated by --- lines. JSON cannot represent more than one root document, so only the first is converted. Split the file into separate documents and convert each one.
My anchors were expanded into duplicate blocks. Can that be avoided?
Not when the target is JSON. Anchors and aliases are a YAML serialisation feature, not part of the underlying data, so a conformant parser resolves them before anything else sees the document. The duplication reflects what the YAML actually meant.
Are my comments recoverable after converting to JSON and back?
No. Comments are discarded at parse time by every conformant YAML parser. Keep the original file if the comments matter.
Does it validate against a schema?
No. It checks that the document is syntactically well formed and converts it. Schema validation for things like Kubernetes or OpenAPI is a separate job and needs the relevant schema definition.
Read more
CSV, JSON, YAML, XML: choosing a data format — Every conversion between these formats loses something. Knowing what, in advance, prevents most of the resulting bugs.