Is JSON valid YAML? What YAML 1.2 promises and where it breaks

Pasting JSON into a YAML file and getting away with it — why that works, and the one time it did not

An ordinary JSON object can be pasted into the YAML source side and read under ToolAcre’s YAML 1.2 JSON schema. Braces, brackets, quoted keys, strings, numbers, booleans and null become the same plain JavaScript value. That explains why the boundary often feels trivial.

The guarantee should remain parser-specific. ToolAcre restricts tags, caps aliases and nesting, and applies an input limit. A text can be valid under a broader YAML processor yet be refused here for safety or shape reasons unrelated to its JSON-looking core.

Ordinary JSON loads through this YAML 1.2 reader; unsupported extensions fail for separate reasons

The selected schemas produce JSON-shaped values: strings, numbers, booleans, null, arrays and mappings. This alignment enables parse-then-serialize rather than punctuation replacement. The source code does not establish every wording or erratum of the YAML specification, so the article reports tested behaviour instead of claiming exhaustive conformance.

Under strict mode, tilde, empty value and `0o755` stay strings. Those are YAML tokens JSON itself would not contain. Core resolves them differently while still returning JSON-shaped output.

The shipped schemas align with JSON-shaped data without proving every specification edge

Duplicate YAML mapping keys keep the last value with a warning; a strict interpretation elsewhere may reject them. Legacy YAML 1.1 readers can type words such as `NO` differently, while this reader keeps them as strings. Those differences complicate broad portability statements.

Tabs used as indentation produce an error, whereas tabs inside quoted JSON strings are escaped. Very deep or oversized values can hit local safety caps. A theoretical language relationship does not override implementation boundaries.

Duplicate keys and legacy-parser differences remain interoperability boundaries

The reverse is plainly false for this value pipeline. YAML comments have no JSON representation, aliases resolve into repeated data, multi-document streams become arrays, and unsupported tags are rejected. Block scalars become strings but their presentation is lost.

Even a supported YAML document can therefore convert to valid JSON and never return to the same YAML text. Data equality may survive for ordinary values while comments, anchors, spelling and stream identity do not.

What this means for conversion — JSON to YAML is a style change, YAML to JSON is a translation that can lose information

JSON-to-YAML is usually a style and serialization change for JSON-shaped input. YAML-to-JSON first interprets YAML-specific syntax and then projects the result into JSON’s smaller value model. The directions are not symmetrical.

ToolAcre tests ordinary JSON-to-YAML-to-JSON documents containing nested values, Unicode, nulls, arrays and ambiguous-looking strings. Those fixtures prove the covered data class, not every possible JSON or YAML processor pair.

Worked example: a JSON document loaded as YAML — the same structure, then a YAML-only feature added to show where JSON tooling stops

Paste `{"country":"NO","items":[1,null],"nested":{"ok":true}}` as YAML input. The strict reader returns the same tree. Add a YAML comment and the value remains the same while the comment disappears. Replace a repeated object with an anchor and alias; the JSON now contains copies rather than reference syntax.

Add `---` and a second document; the result becomes an array of documents with a warning. Add `!!binary`; the restricted reader refuses it. Each step marks a distinct boundary: ignored presentation, resolved structure, stream convention and unsupported type.

What this does not cover — schema-level compatibility, where YAML types like timestamps have no JSON counterpart

Schema compatibility is not only about surface syntax. Core can create Infinity or NaN, which JSON writes as null with warnings. Timestamp and binary tags are refused under the restricted schemas rather than converted. ToolAcre deliberately narrows YAML to safe JSON-shaped data.

Another YAML implementation may support additional types. That makes it less compatible with plain JSON values at those points, not automatically better or worse. Choose based on the target contract and security requirements.

Schema-level compatibility includes non-finite values and temporal tags that this restricted reader limits or refuses

Ordinary JSON-shaped data passes cleanly through this YAML 1.2 reader and writer. Broader claims about all documents or parsers require fixtures covering duplicate keys, schema versions, tags and resource limits.

Use Syntax converters to test the actual text and read its warnings. Treat “JSON is YAML” as a useful shorthand only after naming the parser, schema and unsupported features that make the real boundary precise.

For a portability test, keep one fixture entirely inside JSON’s value model and another that adds one YAML-only feature at a time. Run both through each intended consumer. The first measures the practical subset claim; the second identifies exactly where comments, aliases, streams, tags or scalar rules diverge. This staged method is more informative than asking whether two languages are subsets in the abstract, because it produces failures tied to the parsers your system actually uses.