You're staring at a JSON API response and you need to paste it into a Kubernetes ConfigMap. Or your colleague sent you a YAML Helm values file and your integration test expects JSON. Either way, manually rewriting the format is tedious, error-prone, and a genuine waste of your afternoon.
This is one of those tasks that sounds simple but hides dozens of small traps: indentation levels, quoted strings that need to stay quoted, booleans that change meaning, and nested arrays that look completely different in each format. Let's fix it properly.
Why JSON and YAML Keep Colliding
JSON and YAML represent the same data model — key-value pairs, arrays, nested objects — but they express it differently. JSON uses braces and brackets; YAML uses indentation and dashes. This makes them structurally compatible but visually incompatible.
The collision happens most often in these real-world scenarios:
API responses → Kubernetes manifests. You fetch config data from an API (JSON) and need to embed it in a ConfigMap or Secret (YAML).
GitHub Actions / CI pipelines. Workflow files are YAML, but tool configs (ESLint, Prettier, TypeScript) often live in JSON.
Helm chart values. Default values are YAML; your templating logic might generate JSON alongside them.
Ansible playbooks. Variables defined in JSON need to flow into YAML playbook tasks.
The Conversion Is Mechanical — But Still Fiddly
Here's what the same data looks like in both formats:
JSON:
{
"server": {
"host": "api.example.com",
"port": 8080,
"tls": true
},
"retries": 3,
"tags": ["production", "us-east-1"]
}
YAML equivalent:
server:
host: api.example.com
port: 8080
tls: true
retries: 3
tags:
- production
- us-east-1
Notice the changes: no braces, no quotes around plain strings, arrays become dash-prefixed lists, and the entire structure depends on consistent indentation. One wrong space and your YAML parser throws a fit.
Going the other direction is just as mechanical — but converting by hand still risks mistakes, especially with deeply nested objects.
Converting in the Browser: The Fast Path
Instead of writing conversion code every time, the JSON to YAML Converter handles this in your browser. Paste your JSON on the left, get clean YAML on the right. No sign-up, nothing leaves your browser.
Before converting, make sure your JSON is valid. Compacted API responses or copied-from-logs JSON often have hidden issues — trailing commas, unescaped characters, or single quotes instead of double. Running it through the JSON Beautifier & Validator first formats and validates it in one step, so you're not feeding broken JSON into a converter and wondering why the output looks wrong.
A Real-World Example: Kubernetes ConfigMap
Let's say you have this JSON config coming out of a deployment pipeline:
{
"database": {
"host": "postgres.internal",
"port": 5432,
"name": "app_production",
"ssl_mode": "require"
},
"cache": {
"ttl": 300,
"max_size": 1000
},
"feature_flags": {
"new_checkout": true,
"beta_search": false
}
}
After conversion, you get YAML you can drop directly into a Kubernetes ConfigMap:
database:
host: postgres.internal
port: 5432
name: app_production
ssl_mode: require
cache:
ttl: 300
max_size: 1000
feature_flags:
new_checkout: true
beta_search: false
Clean, indented, and ready to embed. The tool handles the structural mapping — you just verify the output makes sense.
Going the Other Way: YAML Back to JSON
The reverse conversion matters just as much. Your GitHub Actions workflow file is YAML; you want to parse specific values in a script that expects JSON. Or a colleague sends you an Ansible vars file and your test harness is JSON-only.
The same JSON to YAML Converter supports bidirectional conversion — paste YAML in the YAML panel and get JSON back.
One thing to watch for when going YAML → JSON: YAML has native support for timestamps, multi-line strings (| and > blocks), and anchors/aliases (& and *). These don't have direct JSON equivalents, so they get serialized as plain strings or resolved inline. If your YAML uses these features heavily, review the JSON output carefully before using it downstream.
When to Write the Conversion in Code
For a one-off config tweak, the browser tool is the fastest path. But if you're converting as part of a build pipeline or automation script, you'll want code. Here's the idiomatic approach in a couple of common languages:
Python:
import json, yaml
with open("config.json") as f:
data = json.load(f)
with open("config.yaml", "w") as f:
yaml.dump(data, f, default_flow_style=False)
Node.js (with js-yaml):
const fs = require('fs');
const yaml = require('js-yaml');
const data = JSON.parse(fs.readFileSync('config.json', 'utf8'));
fs.writeFileSync('config.yaml', yaml.dump(data));
For interactive exploration or debugging — especially when you're unsure why a converted file looks off — the browser tool remains the quickest feedback loop even if you have automation in place.
Further Reading
If you're curious about where JSON and YAML differ beyond syntax — data type handling, comment support, schema strictness — the JSON vs YAML comparison page goes deeper on the structural tradeoffs between the two formats.
What Format Mismatch Do You Hit Most?
I'm curious — is it mostly the API → config file direction that catches you out, or is YAML → JSON (for testing or scripting) the bigger pain point in your workflow? Drop a comment below.
Free tools used in this post:
JSON to YAML Converter — converts between JSON and YAML formats instantly in the browser, bidirectional
JSON Beautifier & Validator — formats and validates JSON before you convert, catching hidden errors fast
All tools — client-side, no sign-up, nothing leaves your browser
SOCIAL SHARE CARD GENERATOR