YAML to JSON / JSON to YAML Converter bidirectionally converts between YAML and JSON formats. Paste YAML to get minified or pretty-printed JSON, or paste JSON to get clean YAML output. It handles multi-document YAML, anchors and aliases, YAML comments (stripped in JSON output), nested structures, and validates both formats for syntax errors before conversion.
YAML (YAML Ain't Markup Language) is a human-friendly data serialization format that is a strict superset of JSON. YAML uses indentation for structure (no braces or brackets), supports comments (#), multiline strings (| and >), anchors (&anchor) and aliases (*anchor) for reusing values, and multiple document separators (---). JSON (JavaScript Object Notation) uses braces and brackets, requires quoted strings, has no comments, and is more verbose but more widely supported by parsers.
YAML is used in: Kubernetes manifests, Docker Compose, GitHub Actions, GitLab CI, Ansible playbooks, Helm charts, OpenAPI specifications, and configuration files (webpack.config.yaml, .eslintrc.yaml). JSON is the standard for REST APIs, package.json, tsconfig.json, and web data interchange. Converting between them is a common task when working with tools that accept only one format or when making configurations more readable.
Kubernetes config to JSON
Result: apiVersion: v1 / kind: Pod / metadata: / name: mypod → {'apiVersion':'v1','kind':'Pod',...}
GitHub Actions YAML
Result: on: push: branches: [main] → {"on":{"push":{"branches":["main"]}}}
Resolve anchors
Result: defaults: &defaults / timeout: 30 / service1: <<: *defaults → service1 with timeout: 30
What is the difference between YAML and JSON?
YAML is human-readable and writable: no quotes for simple strings, indentation for structure, # comments, multiline strings. JSON is more machine-friendly: strict quoting, explicit braces/brackets, no comments, no ambiguity. YAML has more features: anchors/aliases (DRY reuse), merge keys (<<:), multiple documents (---). YAML is a superset of JSON — all valid JSON is valid YAML. Choose YAML for config files humans edit; JSON for API data interchange.
What are YAML anchors and aliases?
Anchors (&name) define a reusable block and aliases (*name) reference it. Example: defaults: &defaults { timeout: 30, retries: 3 }; service1: { <<: *defaults, port: 8080 }; service2: { <<: *defaults, port: 9090 }. The << merge key inserts all key-value pairs from the referenced anchor. This is YAML's equivalent of inheritance — avoiding repetition in configs. When converted to JSON, anchors are resolved and the full value appears at each usage site.
Can YAML have comments?
Yes — YAML supports comments starting with #. Example: timeout: 30 # seconds. Comments are ignored by parsers and are NOT preserved in JSON output (JSON has no comment syntax). This is a key difference between YAML and JSON for config files: YAML configs can explain why a value is set; JSON configs cannot. The workaround for JSON comments: use a JSON superset like JSON5 or JSONC (JSON with Comments), or use a preprocessing step.
What are common YAML gotchas?
YAML has several surprising behaviors: (1) 'yes', 'no', 'true', 'false', 'on', 'off' are parsed as booleans — use quotes if you mean the string 'yes'. (2) Bare octals: 010 is 8 in YAML 1.1 (Kubernetes uses 1.1), but a string in YAML 1.2. (3) Multiline strings: | preserves newlines (literal block), > folds newlines to spaces. (4) Colons in values: 'key: value: with: colons' needs quoting. (5) Tabs are forbidden for indentation — use spaces only.
When should I use JSON vs YAML for configuration files?
JSON: when other tools, schemas, or APIs require it (package.json, tsconfig.json, AWS CloudFormation). YAML: for human-maintained configs where readability matters (Kubernetes, Docker Compose, CI/CD). Factors favoring YAML: comments needed, less verbose, humans will edit it frequently. Factors favoring JSON: tooling support is universal, JSON Schema validation is mature, no ambiguous types. Many projects accept both (OpenAPI spec, ESLint config, Babel config) — pick what your team prefers.