JSON vs YAML: Który Format Konfiguracji Powinieneś Wybrać?
Quick Answer
Używaj JSON dla API, wymiany danych i przypadków gdzie ścisłe parsing&validation ma znaczenie. Używaj YAML dla plików konfiguracyjnych, manifestów DevOps i gdzie ludzka czytelność i komentarze są ważne. YAML to superset JSON —każdy poprawny JSON to poprawny YAML.
Introduction
JSON i YAML to oba ludzko-czytelne formaty serializacji danych. JSON jest ścisły, minimalny i wszechobecny w web API. YAML to superset JSON, który dodaje komentarze, multiline strings, anchors i strukturę opartą na indentacji —co czyni go popularnym dla plików konfiguracyjnych (Docker Compose, Kubernetes, CI/CD).
Step by Step
-
Compare syntax and readability
JSON uses braces and quotes: {"key": "value"}. YAML uses indentation and colons: key: value. YAML is cleaner for configuration — no quotes needed for strings, no commas between items, no braces. JSON is more explicit and less error-prone for data interchange.
-
Compare features
YAML supports: comments (#), multiline strings (|, >), anchors (&) and aliases (*), multiple documents in one file (---), and complex types. JSON supports none of these — no comments, no multiline strings, no references. JSON's simplicity is intentional: it's a data interchange format, not a configuration language.
-
Compare safety and parsing
JSON parsing is fast and safe — JSON.parse is built into every JavaScript engine. YAML parsing is slower and more complex — YAML spec is 80+ pages vs JSON's 2 pages. YAML has security risks (billion laughs attack via anchors) that JSON doesn't. Always use a safe YAML parser that disables anchors.
-
Compare ecosystem usage
JSON: REST APIs, package.json, tsconfig.json, NoSQL databases, web apps. YAML: Docker Compose, Kubernetes manifests, GitHub Actions, Ansible playbooks, CI/CD configs, OpenAPI specs. JSON dominates runtime data; YAML dominates configuration.
-
Decide based on your use case
APIs, data interchange, NoSQL, web app state: JSON. Configuration files, DevOps, CI/CD, infrastructure-as-code: YAML. If humans write it by hand: YAML. If machines generate and consume it: JSON.
Examples
Same config in JSON and YAML
Input: JSON: {"server": {"port": 8080, "host": "localhost"}}
YAML: server:\n port: 8080\n host: localhost
Output: YAML is 30% shorter and supports comments. JSON is stricter and universally parseable.
Common Problems
- YAML indentation errors: YAML uses indentation for structure, and a single wrong space breaks parsing — use an editor with YAML linting and always use spaces, never tabs.
- YAML billion laughs attack: YAML anchors and aliases can create exponential expansion, causing DoS — use a safe YAML parser that disables anchors (e.g. yaml.safe_load in Python).
- JSON has no comments: JSON spec forbids comments, making configuration files harder to annotate — use YAML for human-edited config, JSON for machine-generated data.
- YAML implicit typing surprises: YAML auto-converts yes/no to booleans and 1.0 to float, which can break string fields — quote strings explicitly to avoid unexpected type coercion.
Tips
- Use YAML for human-authored configuration (Docker Compose, Kubernetes, CI/CD) and JSON for machine-generated data interchange (APIs, NoSQL, app state).
- Always use a safe YAML parser that disables anchors and aliases — never use a general-purpose YAML loader on untrusted input.
- When converting YAML to JSON, expect to lose comments, multiline strings, and anchors — JSON is a subset of YAML, not the other way around for features.
- Indent YAML with 2 spaces consistently — mixing tabs and spaces or using inconsistent indentation is the most common YAML parsing error.