yml vs yaml — any difference?
None. .yml and .yaml are the same format. The official YAML spec and the tooling treats them identically. The .yaml extension is the officially recommended one (since YAML 1.2), but .yml was popularized by older Windows/DOS filesystems that capped extensions at three characters. Both are here to stay.
Some tools have opinions: GitHub Actions accepts both .yml and .yaml for workflow files. Docker Compose historically preferred docker-compose.yml but now supports both. Kubernetes examples use .yaml consistently. Ruby on Rails uses .yml. Ansible accepts either.
Pick one convention per project; never mix. Our converter doesn't care which extension — it operates on content, not filename.
Writing YAML comments and multi-line strings
YAML's two features that JSON lacks: comments and readable multi-line strings.
# This is a comment — starts with # to end of line
database:
host: db.example.com
port: 5432
# Password pulled from env at runtime — don't hardcode
password_ref: ${DB_PASSWORD}
# Multi-line strings — three flavors
description_literal: |
Keeps newlines exactly as written.
Each line is literal.
Trailing newline preserved.
description_folded: >
Folds newlines to single spaces.
This makes one long paragraph on output.
description_plain:
A simple single-line value
continues across indented lines
— most tools handle this
Chomping indicators modify trailing-newline behavior: |- strips final newline, |+ keeps all trailing newlines. Our converter preserves whichever you use when converting YAML ↔ JSON ↔ TOML.
YAML vs JSON vs TOML — when to use which
| JSON | YAML | TOML | |
|---|---|---|---|
| Syntax feel | Strict, compact | Indentation-sensitive, readable | INI-like with sections |
| Comments | No | Yes (#) | Yes (#) |
| Types | string, number, bool, null, array, object | same + timestamps, references, multi-line strings | same + typed arrays, inline tables |
| Whitespace-sensitive | No | Yes — this is the #1 gotcha | No |
| Common use | APIs, NoSQL docs, package.json | Kubernetes, GitHub Actions, Docker Compose, Ansible | Rust Cargo.toml, Python pyproject.toml, Hugo config |
| Parser gotchas | None (strict spec) | "Norway bug" (NO → false), 8-space-vs-tab errors | None (strict spec) |
Pick YAML for heavily-nested configs humans will edit (Kubernetes manifests). Pick TOML for flat+section configs (Cargo, pyproject). Pick JSON for API wire formats and anything machine-generated.
The YAML "Norway bug" and other indentation traps
YAML's biggest footgun: it tries to be helpful by guessing types, sometimes wrong.
countries:
- NO # parses as boolean false! (ISO 639-1 "NO" / Norwegian)
- "NO" # parses as string "NO" — safe
# Other booleans:
yes, no, on, off, true, false, Yes, No, On, Off, True, False, YES, NO ...
# all parse as boolean in YAML 1.1. Quote to be safe.
# Number parsing:
version: 1.10 # parses as 1.1 (trailing zero dropped)
version: "1.10" # string — safe for version numbers
# Indentation:
servers:
- name: a
- name: b
config: # ⚠ is this under servers or root? depends on spaces
timeout: 30
Safer alternatives: YAML 1.2 (strict, parses NO as string, but many tools stuck on 1.1) or "just use JSON where you can."
Frequently Asked Questions
How do I convert YAML to JSON online?
Paste YAML into the left panel. JSON renders instantly on the right with preserved key ordering and correct type inference (strings, numbers, booleans, null, arrays, objects). Round-trip safe — convert back with no data loss.
How do I convert JSON to YAML for Kubernetes or Docker Compose?
Paste JSON on the left, pick YAML as the target. The converter produces idiomatic YAML with 2-space indentation (Kubernetes convention). Paste directly into `kubectl apply -f`, `docker-compose.yml`, or any YAML-based config.
Can this converter handle TOML (Cargo.toml, pyproject.toml)?
Yes. TOML is fully supported as source or target. Convert a `Cargo.toml` to JSON for CI inspection, or a JSON API response to TOML for a Rust/Python project config.
What's the difference between YAML, JSON and TOML?
JSON = universal, strict syntax, easy to parse, no comments. YAML = human-friendly with indentation, comments, anchors — but whitespace-sensitive gotchas. TOML = configuration-focused, explicit types, unambiguous. Pick based on audience: JSON for APIs, YAML for Kubernetes/GitHub Actions, TOML for Rust/Python.
Does the converter preserve comments when switching formats?
JSON has no comment syntax, so YAML → JSON drops comments. YAML ↔ TOML preserves comments. A warning shows when comments will be lost — so you don't silently lose context.
Smarter quality checks. Faster deployments.
Better apps.
