Convert JSON to YAML

JSON and YAML are functionally equivalent — they both represent the same data types (strings, numbers, booleans, null, arrays, and objects) and can represent the same structures. The difference is entirely syntactic: JSON uses curly braces, square brackets, colons, commas, and double quotes. YAML uses indentation, dashes for list items, colons followed by spaces, and optionally no quotes at all for strings. YAML's lower punctuation density makes it the preferred format for configuration files that humans read and edit frequently. This example converts a realistic application configuration with four sections to YAML. The JSON uses nested objects with string, number, and boolean values, plus an array in the features field. In the YAML output: each nested JSON object becomes an indented block, the colon-space (:) separator replaces the JSON colon inside objects, boolean false and true appear unquoted, and the JSON array ["auth", "logging", "metrics"] becomes a YAML sequence with dash-prefixed items. Where YAML is preferred: Kubernetes manifests, Helm charts, Docker Compose files, GitHub Actions workflows, GitLab CI pipelines, Ansible playbooks, and AWS CloudFormation templates are all standardized on YAML. The ecosystem tooling for these platforms is built around YAML, and their documentation uses YAML in all examples. Converting a JSON configuration to YAML is often the first step when adapting a JSON-based configuration to one of these platforms. Where JSON is preferred: REST API payloads, configuration files processed by JavaScript applications (package.json, tsconfig.json), and any format where a standard JSON parser is expected. JSON has stricter syntax that makes it less error-prone for machine processing, while YAML's flexibility (multiple equivalent syntaxes, complex string quoting rules) can cause subtle bugs. YAML gotchas to watch for after conversion: values like yes, no, true, false, on, off are parsed as booleans in YAML 1.1 (used by many older parsers) — the string "no" becomes the boolean false. Numbers like 0755 are parsed as octal. Port numbers like 1234 are parsed as integers. If the original JSON used string values for these, the converter adds quotes in the YAML output to preserve the string type. Comments advantage: one of YAML's key benefits over JSON is comment support. After conversion, you can add # comments to document configuration choices, reference documentation URLs, or note which environment a value applies to. JSON has no comment syntax. Real-world scenario: converting a microservice's JSON application config to YAML to use as a Helm values file, where the YAML format is required and comments can document which values should differ per environment.

{
  "app": {
    "name": "my-service",
    "version": "2.0.0",
    "port": 8080,
    "debug": false
  },
  "database": {
    "host": "localhost",
    "port": 5432,
    "name": "appdb",
    "ssl": true
  },
  "features": ["auth", "logging", "metrics"],
  "limits": {
    "maxConnections": 100,
    "timeoutMs": 5000
  }
}