JSON to YAML Converter
Convert between JSON and YAML formats instantly. No external libraries needed. 100% client-side processing.
No data sent to serverRelated Tools
What are JSON and YAML?
JSON (JavaScript Object Notation, RFC 8259) and YAML (YAML Ain't Markup Language, spec 1.2.2) are both human-readable data formats. They represent the same fundamental data — objects, arrays, primitives — with different syntax. JSON uses braces and brackets with strict quoting; YAML uses indentation and is more lenient.
When to use which
JSON dominates web APIs and inter-service communication. Compact, fast to parse, no ambiguity. YAML dominates configuration files — Kubernetes manifests, Docker Compose, GitHub Actions workflows, Ansible playbooks, GitLab CI, AWS CloudFormation, dbt, Hugo. The support for comments and the indentation-based readability tip the balance for human-edited configs.
Why convert between them?
Mixed-tool environments. Your CI generates JSON metrics but you need to commit YAML configs. Your API returns JSON but your deployment YAML reads from it. Some tools accept only one format. Conversion is the lubricant in modern DevOps pipelines.
How to Use
- Select direction: JSON → YAML or YAML → JSON.
- Paste your data in the input field. Conversion runs automatically as you type.
- For JSON → YAML: indentation defaults to 2 spaces; strings are quoted only when needed;
nullstays asnull. - For YAML → JSON: comments (lines starting with
#) are stripped; type coercions follow YAML spec. - Click Copy to copy the result, or Swap to reverse the direction with the output as new input.
JSON vs YAML — Side by Side
Same data in both formats
# JSON
{
"name": "myapp",
"version": "1.0.0",
"ports": [80, 443],
"env": {
"DEBUG": false,
"DATABASE_URL": "postgres://..."
},
"tags": ["web", "production"]
}
# YAML (same data)
name: myapp
version: 1.0.0
ports:
- 80
- 443
env:
DEBUG: false
DATABASE_URL: postgres://...
tags:
- web
- productionFeature comparison
| Feature | JSON | YAML |
|---|---|---|
| Comments | ❌ | ✅ # |
| Multi-line strings | ❌ (escape only) | ✅ | and > |
| Anchors / aliases | ❌ | ✅ &name / *name |
| Type-strict | ✅ explicit | ⚠️ implicit (coerces "yes" → true) |
| Trailing commas | ❌ | N/A |
| Parse speed | ⚡ Fast | 🐢 5–10× slower |
| File size | Compact | More readable |
| Ambiguity | None | Several gotchas |
YAML Gotchas (the "Norway problem")
YAML's permissive type coercion causes famous bugs.
1. Boolean coercion ("Norway problem")
YAML 1.1 treats NO, no, No, YES, off, on as booleans. The country code NO (Norway) silently becomes false:
# YAML 1.1 (still default in many parsers!) countries: - US - GB - NO # becomes 'false', not "NO"! # Fix: quote the string - "NO"
YAML 1.2 (2009 spec) restricts booleans to true / false only — but many parsers still default to 1.1. Always quote strings that look like booleans.
2. Octal numbers
port: 0644 in YAML 1.1 is octal (= 420 decimal), not the string "0644". Common bug in Kubernetes manifests with file permissions.
3. Indentation must be consistent
Mixing tabs and spaces in YAML is a parser error. Use spaces only (typically 2). Tabs in the wrong place produce cryptic "could not find expected ',' or '}'" errors.
4. Strings vs numbers
version: 1.0 is a number (1.0 → 1). version: "1.0" is the string "1.0". Critical for semver fields. Same for phone numbers, ZIP codes, serial numbers — quote anything that looks like a number but isn't intended as one.
5. Multi-line strings
YAML has two multi-line forms: | (literal, preserves newlines) and > (folded, joins lines with spaces). They're not interchangeable:
message: | Line 1 Line 2 # Result: "Line 1\nLine 2\n" message: > Line 1 Line 2 # Result: "Line 1 Line 2\n"
FAQ
Does this support all YAML features?
Yes for common cases: objects, arrays, strings, numbers, booleans, null, and nested structures. Anchors / aliases (&name / *name), tags (!!str), and explicit document separators (---) work for parsing but are simplified during conversion.
Can YAML have comments?
Yes, YAML supports comments with #. JSON does not. Comments are lost when converting YAML → JSON. For JSON-with-comments, use JSONC (VS Code's flavor) — but strict JSON parsers will reject it.
Why is my YAML breaking?
Most likely indentation. YAML is whitespace-sensitive — tabs and spaces don't mix, and inconsistent indent levels produce parser errors. Use a YAML linter (yamllint) to catch these. The Norway problem (above) is the second most common bug.
Is YAML faster or slower than JSON?
YAML parsing is 5–10× slower than JSON because the grammar is much more complex. For runtime performance (API responses), JSON wins. For human-edited configs (parsed once at startup), the speed difference doesn't matter.
Are JSON and YAML 1.2 fully compatible?
YAML 1.2 (2009) is officially a superset of JSON — every valid JSON is valid YAML. But not vice versa: YAML features like anchors, multi-line strings, and tags have no JSON equivalent. Conversion preserves data but loses YAML-specific features.
⚠️ 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.
📖 Related Guides
Color Formats — HEX, RGB, HSL, OKLCH
Modern CSS color formats explained. When to use OKLCH for perceptual uniformity.
REST vs GraphQL vs gRPC — Choosing an API Paradigm
Trade-offs across performance, tooling, type safety, and team shape. When to use each.
UUID v4 vs ULID — Which to Choose?
Compare UUID v4 and ULID for distributed systems. Performance, sortability, and use cases.