Convert JSON to YAML Online
Convert JSON to readable YAML. Ideal for creating Docker Compose, Kubernetes, or GitHub Actions configs.
name: John Doe age: 30 active: true tags: - developer - javascript address: city: Madrid zip: 28001
Use cases
From API JSON to readable YAML configuration
Create DevOps configs
Transform JSON responses from Kubernetes, Docker, or cloud tool APIs into editable YAML configuration files.
DevOps workflow
Convert CloudFormation or Azure ARM JSON templates to equivalent YAML for improved readability and maintainability.
100% private
Your JSON is processed in your browser. Never uploaded to any server. No signup, no usage limits.
Clean YAML
2-space indentation, correctly typed values, ready to paste into docker-compose.yml or a Kubernetes manifest.
How it works
Three steps, no hassle
Paste your JSON
Paste any valid JSON: API response, configuration, structured data. Both formatted and minified JSON accepted.
Conversion to clean YAML
JSON is converted to YAML with 2-space indentation, following conventions of the most popular DevOps projects.
Copy and use the YAML
Copy the resulting YAML to use as the basis of your docker-compose.yml, Kubernetes manifest, or any YAML config.
FAQ
Got questions?
YAML outperforms JSON in readability for long, hierarchical configurations. The main advantages of YAML are: comment support (essential in documented config files), more concise syntax (no braces or quotes in most cases), better multi-line string representation (scripts, commands, text), and more natural list reading. JSON is superior when the destination is an API or a program processing it automatically: parsing is faster, the spec is simpler and stricter, and there is less ambiguity. The practical DevOps rule: YAML for files humans edit directly, JSON for data exchanged between systems.
The converter generates YAML structurally equivalent to the input JSON, without comments (JSON has no comments, so there is no information to transfer). However, the generated YAML is an excellent starting point: open it in any editor and add comments manually with # before or after any line. In tools like docker-compose.yml and Kubernetes manifests, comments are fundamental for documenting the purpose of each configuration value.
JSON is considerably faster to parse than YAML. JSON parsing is O(n) with very low constants: parsers like simdjson (used in Node.js since version 17) process up to 3 GB/s on modern hardware. YAML requires a more complex parser (handling anchors, aliases, explicit types, various string styles) and is typically 10-50x slower than JSON for the same data volume. For small config files (a few KB docker-compose.yml), the difference is imperceptible. For APIs exchanging millions of messages per second, JSON is the right choice. YAML's use in DevOps tools is an ergonomics decision for the humans editing those files.
The converter uses 2-space indentation, which is the convention adopted by virtually the entire DevOps ecosystem: Kubernetes (kubectl generates YAML with 2 spaces), Helm, GitHub Actions, GitLab CI, Ansible, and Docker Compose. Some projects use 4 spaces (common in Python projects where the PEP 8 4-space convention influences developers), but 2 spaces is the de facto standard in the DevOps community.
Type conversion is straightforward: JSON numbers (integers and floats) are represented as unquoted YAML scalars; JSON booleans (true/false) become true/false in YAML; JSON null becomes null or ~ in YAML; strings are represented without quotes when unambiguous, or in single or double quotes when the value could be interpreted as another type (for example, the string '42' needs quotes to avoid becoming a number, and 'true' needs quotes to avoid becoming a boolean).
Convert JSON to YAML: from API responses to readable DevOps configurations
Converting JSON to YAML is a routine operation in modern DevOps workflows. The Kubernetes APIs (the Kubernetes REST API returns resources in JSON by default), AWS CloudFormation, Azure Resource Manager, Google Cloud Deployment Manager, and most infrastructure-as-code tools have native JSON interfaces, but their users prefer working with YAML configuration files for better readability. kubectl, the Kubernetes command-line tool, automatically converts between YAML and JSON: when you run kubectl get deployment my-app -o yaml, Kubernetes returns the JSON API object and kubectl converts it to YAML for display. The reverse conversion (JSON to YAML) is useful when creating a YAML manifest from an API response, when migrating configurations between tools, or when documenting an existing configuration by adding YAML comments.
YAML (specification 1.2, published at yaml.org in July 2009) is a superset of JSON, guaranteeing that JSON-to-YAML conversion is always possible without information loss. The reverse (YAML to JSON) only loses comments, which JSON cannot represent. The advantages of YAML for human configurations are well documented: the absence of braces and brackets reduces visual noise by 30-40% for typical configurations; comments allow documenting the purpose of each parameter directly in the file; multi-line strings (especially with the literal block |) allow including shell scripts, SQL queries, or file contents directly in the configuration without escaping special characters.
In the Kubernetes ecosystem, the choice between YAML and JSON is well established: files that developers create and maintain in git repositories are YAML; data kubectl sends to the API server is JSON (kubectl converts YAML to JSON internally before making the HTTP call); API server responses are JSON; and automation tools (Helm, Kustomize, Argo CD, Flux) work with YAML as input and JSON as the internal protocol. This separation between human format (YAML) and protocol format (JSON) is a pattern also followed by GitHub Actions (workflows are YAML, the GitHub API is JSON), GitLab CI, Ansible (playbooks in YAML, dynamic inventory data in JSON), and Terraform (HCL is HashiCorp's alternative, but it also accepts native JSON in .tf.json files).