EN
PT
ES
JSON ↔ YAML Converter
Round-trip between JSON and YAML in your browser — perfect for Kubernetes, GitHub Actions, Helm and CI configs.
What is YAML good for?
YAML is JSON's friendlier cousin: same data model (objects, arrays, strings, numbers, booleans, null), but with whitespace-significant indentation instead of braces and brackets, plus support for comments. That makes YAML the dominant format for human-edited configuration files — Kubernetes manifests, Helm values, GitHub Actions workflows, CI pipelines, Docker Compose, Ansible playbooks, and most modern app configs all live in YAML. JSON, on the other hand, dominates wire formats and APIs because every language can parse it without thinking. This converter lets you bounce between the two without leaving the browser. JSON → YAML is what you do when you want to take an API response and turn it into a Kubernetes manifest, or take a Postman collection and reformat it for a tutorial. YAML → JSON is what you do when a tool insists on JSON and your config is YAML, or when you want to validate a YAML file against a JSON Schema. Everything is converted right in your browser tab — no upload, no logging, no copy of your manifests held on someone else's server. That makes the tool safe even for production-grade Helm values or workflow files that contain internal hostnames, secrets references and infrastructure details.
How to use it
Pick a direction, paste your data, click Convert. The result appears below with a copy button.
- Pick the direction — Use JSON → YAML to turn API responses or generated configs into something humans can edit. Use YAML → JSON when a tool needs JSON or you want to send a YAML config to an HTTP API.
- Try a preset — Click Kubernetes Service, GitHub Action, or App config to load a representative example you can edit and convert. The preset matches your current direction.
- Pick indentation — 2 spaces is what most YAML linters and ecosystem tools expect (Kubernetes, Ansible, Helm). Use 4 spaces only if your team has explicitly standardized on it.
- Sort keys for stable diffs — Toggle Sort keys A→Z to make the output alphabetically ordered. This is great for git diffs and snapshot tests when two tools emit the same data with different key orders.
Mapping rules between formats
Both formats share the same logical model, so most values round-trip identically. Strings, numbers, booleans, null, arrays and objects map one-to-one. The converter follows the modern YAML 1.2 spec, which (unlike YAML 1.1) does not treat yes, no, on, off as booleans — only true and false — so you avoid the legendary "Norway problem" where the country code NO silently becomes the boolean false. Multi-line strings in YAML use literal (|) or folded (>) blocks; converting from JSON, this tool emits regular quoted strings with \n escapes for portability. Comments only exist in YAML; converting JSON → YAML → JSON discards comments because JSON has nowhere to put them.
Quick reference
A handful of values and how they translate between the two formats.
| JSON | YAML |
|---|---|
{ "a": 1 } | a: 1 |
[1, 2, 3] | - 1 |
"yes" | 'yes' (quoted to keep it a string) |
null | null (or empty / ~) |
"line\nbreak" | "line\nbreak" |
{ "n": 1.0 } | n: 1.0 (stays a float) |
Frequently asked questions
Why is my YAML showing the string "true" as a boolean?
YAML treats unquoted true and false as booleans. If you want the literal three-letter string, quote it: flag: "true". The converter respects whatever you wrote.
Does it handle multi-document YAML files?
YAML supports multiple documents in one file, separated by ---. This converter parses the first document only when going to JSON. For Kubernetes manifest bundles, split your file before pasting, or convert each document separately.
Why are my YAML comments missing after the round-trip?
JSON does not support comments. When you go YAML → JSON, all comments are dropped. The reverse trip JSON → YAML cannot recover them. Keep a copy of the YAML if comments matter to you.
Is the conversion lossless for typical configs?
For Kubernetes, GitHub Actions, Docker Compose and similar configs — yes, with the only loss being comments and the specific style of multi-line strings. Numbers, dates parsed as ISO strings, booleans, nested maps and arrays all round-trip cleanly.
What about anchors and aliases (&ref / *ref)?
Anchors and aliases are resolved when parsing, so the JSON output contains the materialized values that the YAML referenced. The reverse direction does not reintroduce anchors automatically — if you rely on them to keep DRY configs short, you will need to re-add them by hand after converting back to YAML.
Is anything sent to a server?
No. The whole conversion runs entirely inside your browser tab, so the YAML or JSON you paste — including production manifests, secrets references and internal infrastructure names — never reaches our servers or any third party.