YAML ↔ JSON Converter

YAML (YAML Ain't Markup Language) is a human-readable data serialization format that uses indentation to express structure rather than brackets and braces. Its minimal syntax and support for comments make it popular for configuration files in Docker Compose, Kubernetes manifests, Ansible playbooks, GitHub Actions workflows, Helm charts, and most modern CI/CD pipelines. YAML also supports multi-line strings, anchors and aliases (to reuse values), and custom tags — features that JSON entirely lacks.

JSON (JavaScript Object Notation) is a strict, minimal data interchange format derived from JavaScript object literal syntax. It is the universal format for web APIs and is natively parsed by every programming language. JSON requires double-quoted keys and string values, explicit commas between elements, and curly braces and square brackets for objects and arrays. It has no support for comments, trailing commas, or unquoted strings. This strictness, while less readable, makes JSON simpler to parse and less prone to surprising behavior.

YAML is technically a superset of JSON — valid JSON is valid YAML, though the YAML parser interprets it. This means you can always convert JSON to YAML without data loss. The reverse is not always true: YAML features like comments, multi-line strings (block scalars), anchors, and complex key types do not have JSON equivalents and are discarded or must be serialized as strings when converting to JSON.

YAML's implicit type conversion system is a frequent source of bugs. In YAML 1.1 (used by many popular parsers), the unquoted values true, false, yes, no, on, off are parsed as booleans. The value 0755 is parsed as octal (493 decimal). A value like 1e3 is parsed as the float 1000.0. Country code 'NO' and month abbreviation 'Oct' are both parsed as non-string values by lenient parsers — this is the source of the famous 'Norway problem' in Kubernetes and Docker configurations. Quote string values that could be misinterpreted, or upgrade to YAML 1.2 which eliminates most of these implicit conversions.

The choice between YAML and JSON for configuration files involves real tradeoffs. YAML is more readable for humans writing and editing configuration by hand, especially for deeply nested structures. JSON is better for machine-generated or machine-consumed configuration because it has no parsing ambiguity. Some projects (like TOML and Dhall) exist specifically to address the limitations of both formats. For API communication, JSON is the clear standard. For configuration files that humans edit frequently, YAML is often preferred despite its footguns.