JSON to YAML Converter
Convert JSON data to YAML format instantly. Paste text or upload a .json file.
No data sent to serverRelated Tools
What is JSON to YAML?
JSON dominates web APIs (compact, fast to parse). YAML dominates configuration files (readable, supports comments). Converting JSON → YAML is common when migrating API responses to config files or when you need to hand-edit machine-generated data.
Common scenarios: Kubernetes manifests (when a tool outputs JSON, convert for readability), Docker Compose migration, GitHub Actions / GitLab CI workflow drafts, OpenAPI specs (Swagger UI exports JSON, but humans prefer YAML), Helm values files, Ansible playbooks from automation tools.
Conversion example
# JSON
{
"name": "myapp",
"version": "1.0.0",
"ports": [80, 443],
"env": { "DEBUG": false, "PORT": 3000 }
}
# YAML
name: myapp
version: 1.0.0
ports:
- 80
- 443
env:
DEBUG: false
PORT: 3000JSON vs YAML — when each wins
- JSON: APIs (compact, fast parse), inter-service messaging, browser fetch responses, log lines
- YAML: configs (readable, comments allowed), Kubernetes/Docker, CI/CD, infrastructure-as-code, data with anchors/aliases for DRY
Trade-off: YAML parses 5–10× slower than JSON and has type-coercion quirks (the famous “Norway problem” — country code NO becomes false). Choose JSON for runtime, YAML for config.
YAML pitfalls to know
- The Norway problem:
NO,yes,off,oncoerce to booleans in YAML 1.1 — quote them as strings if needed - Octal numbers:
0644→ 420 decimal in YAML 1.1 (file permissions trap) - Indentation: spaces only — never tabs. Inconsistent indent breaks parsing
- Strings vs numbers:
version: 1.0is a number; quote as“1.0”if you mean the string - Anchors / aliases: not supported in JSON; this conversion direction (JSON→YAML) won’t lose anything
How to Use
- Paste JSON data, or upload a
.jsonfile. - Click Convert.
- Review the YAML — verify indentation and types.
- Copy or download as
.yaml/.yml.
Privacy: Conversion runs in your browser.
Making Configuration Readable Again
This conversion is usually the first step in adopting a config file for humans to maintain. An API response or exported settings blob arrives as JSON, and it needs to become something a person can read, comment, and edit without counting brackets.
YAML removes almost all the punctuation. Nesting is expressed by indentation, strings usually do not need quotes, and lists are simple hyphenated lines. A deeply nested JSON object that takes real effort to follow becomes something you can scan.
Because YAML is a superset of JSON, the conversion is lossless: every value, type, and structure carries over exactly.
After Converting, Add What JSON Could Not Hold
The output is correct YAML but not yet good YAML, because the source could not express the things that make YAML worth using.
Add comments. This is the main reason to be in YAML at all. Explain why a timeout is 30 seconds, or which values are safe to change.
Introduce anchors for repeated blocks. If the same configuration appears in several places, define it once with an anchor and reference it, so future edits happen in one spot.
Quote the dangerous values. Version numbers such as 1.10, country codes such as no, and anything time-like should be quoted so YAML does not reinterpret them as numbers or booleans.
Use block scalars for long text. Multi-line strings read far better with the pipe syntax than as one enormous quoted line.
FAQ
Is the YAML output valid for Kubernetes?
Yes — output follows YAML 1.2 syntax compatible with Kubernetes (kubectl), Docker Compose, GitHub Actions, GitLab CI, Ansible. Add a leading --- for multi-document YAML if combining manifests.
How are null values handled?
JSON null becomes YAML null (or empty value). Both are valid representations.
Can I add comments to the YAML?
Comments are added after conversion — the conversion can’t infer where comments should go. Edit the YAML to add # comments where helpful.
What’s the file extension — .yaml or .yml?
Both work. .yaml is the official spec recommendation; .yml exists for historical reasons. GitHub recognizes both. Pick one for project consistency.
Why does my YAML output look slightly different from what I expected?
YAML has multiple equivalent forms — flow vs block, quoted vs unquoted, etc. The output uses block style (most readable). For exact format control, use a parser library with custom emitter options (e.g., js-yaml).
Is any data lost converting JSON to YAML?
No. YAML is a superset of JSON, so every structure and value converts exactly. Only formatting choices change.
Why does the output use block style instead of inline?
Block style with indentation is what makes YAML readable, which is the usual reason for converting. Inline flow style would look almost identical to the JSON you started with.
Should I quote values in the output?
Quote anything that could be misread — version numbers like 1.10, values such as no and yes, and time-like strings. YAML applies type inference to unquoted values, which occasionally surprises people.
Can I convert back to JSON later?
Yes, and the data will round-trip exactly. Only comments and anchor structure are lost on the way back, since JSON cannot represent them.
Are long strings wrapped?
Long values are kept on a single line rather than folded, because folding changes how some parsers interpret whitespace. Convert them to block scalars by hand if readability matters more than exactness.
Does the key order change?
No. Properties appear in the same order as the JSON source, which keeps diffs readable when the file is under version control.
⚠️ Reference Only
Output is generated based on your input and is provided for reference. Results may vary depending on your specific use case, edge cases, or environment-specific behavior. We do not guarantee accuracy of conversions, validations, or computed values.
Always verify critical outputs against official documentation or production environments. We are not responsible for any decisions or losses based on these tool results.