YAML → JSON parses the document — anchors resolved into copies, implicit types applied — and re-emits it as 2-space-indented JSON. Because YAML 1.2's data model is a superset of JSON's, every single-document YAML with standard types converts; comments are dropped, since JSON has no syntax for them.
YAML's terseness is measurable: converting all 26 documents of our sample corpus (parsed and re-emitted with the same yaml library this page uses), the pretty-printed JSON output was larger than its YAML equivalent by a median 45.3% (min 32.9%, max 78.6%) — JSON pays for braces, quotes and commas that YAML's indentation replaces. The trade goes the other way at parse time, where JSON parsers are dramatically faster.
“Invalid YAML: …” quotes the parser's first complaint — most often a tab used for indentation (YAML forbids tabs) or inconsistent indent depth. If conversion succeeds but a value has the wrong type — no became false, 01234 became a number — that is YAML's implicit typing working as specified: quote the value in the YAML source and convert again. Multi-document files (--- separators) must be split first.
Convert when a tool only accepts JSON, when you want to audit what YAML's type guessing actually produced, or when you need configs in a canonical diffable form.
This page is a focused view of theJSON ↔ YAML Converter, which has the full set of options.
Single-document YAML with standard types, yes — YAML 1.2's data model is a superset of JSON's. Multi-document files (--- separators) must be split first, and exotic tags have no JSON equivalent.
YAML's implicit typing: unquoted no, yes, on, off parse as booleans in many parsers, and 007 becomes the number 7. Quote values in the YAML source when they must stay strings — converting to JSON is a quick way to audit for exactly these surprises.
They are resolved during parsing: every alias is replaced by a copy of the anchored value, so the JSON output contains the expanded data.