JSON to YAML: Differences, Edge Cases & Pitfalls

Convert JSON to YAML with safe quoting for numeric-looking strings and block scalars for multi-line values.

The gain from YAML is readability and comments — the latter exist only on the YAML side. The cost is implicit typing: unquoted 1.0, on and yes are typed, so strings need explicit quotes. That is the most common source of semantic drift in a JSON-to-YAML round trip.

Format Differences

AspectJSONYAML
CommentsNot supported by the standardSupported with #, the main win for configs
IndentationNot significant; braces and commas ruleSignificant — bad indentation fails to parse
Implicit typingStrings must be double-quotedUnquoted scalars are inferred (1.0 may become a string)
Multi-line textEscaped with \nBlock scalars | and > suit long text
AnchorsNot supported& defines and * references, enabling reuse
Tab charactersAllowed as whitespaceNever valid for indentation
SizeMore braces and quotes, slightly largerUsually more compact
Parse speedFast, simple structureSlower, type inference costs

Edge Cases

  • Strings that look numeric or boolean ("1.0", "on", "yes", "null") are typed in YAML and must be quoted to stay strings.
  • Strings starting with a colon or special character also need quoting or they parse as mapping keys.
  • Dotted keys are not split into nesting in YAML (that is TOML behaviour), but consumers using dotted paths get confused.
  • Anchors do not exist in JSON, so YAML to JSON expands them into duplicated data, inflating size and losing the reference.

Common Pitfalls

  • Emitting without quotes turns "1.0" into the number 1 downstream and breaks every version comparison.
  • Long text becomes a block scalar and the consumer library cannot parse it, yielding literal | characters.
  • Expecting YAML comments to survive a JSON round trip — they cannot, JSON has nowhere to put them.
  • Indenting with tabs in mixed CJK/Latin files makes YAML refuse to parse outright.

Related Tools