Two-way YAML ↔ JSON conversion with error positions.

Switch tool
YAML0 chars · 0 lines
JSON0 chars · 0 lines

How to use

Purpose

YAML and JSON bidirectional converter. Handles complex nesting, arrays, objects, strings, numbers, booleans, null, comments (lost on YAML→JSON), YAML multi-documents (--- separators), anchors and references (&anchor / *ref), multiline strings (| preserves newlines, > folds whitespace). Common in Kubernetes manifests, CI configs (GitHub Actions / GitLab CI), Docker Compose, application config (Spring Boot application.yml). All conversion runs locally.

Steps

  1. Paste YAML or JSON on the left; format is auto-detected
  2. Right pane shows the converted output in real time
  3. YAML → JSON: comments are dropped (JSON has no comment syntax)
  4. JSON → YAML: default 2-space indent, optional 4-space
  5. Multi-document YAML (--- separated) converts to a JSON array
  6. Anchors (&anchor) and references (*ref) are expanded into repeated objects
  7. Multiline strings (| > |+ |-) preserve their semantics
  8. Syntax errors highlighted: inconsistent indent, unclosed quotes, tab characters (YAML forbids)

FAQ

Why is YAML so sensitive to indentation?
YAML uses indentation for hierarchy (like Python), not braces. Indent must use spaces (no tabs). Same-level keys must have identical indent. This keeps YAML clean but error-prone. Best practice: configure your editor to enforce 2-space indent and show invisible characters.
Are yes/no/on/off parsed as booleans in YAML?
In YAML 1.1, yes/no/on/off/true/false/y/n are all booleans (the famous "Norway problem" — the NO country code parsed as false). YAML 1.2 (2009) only recognizes true/false. But many old libraries (PyYAML) still default to 1.1. Safe play: always quote strings, especially "yes", "no", "off".
What is the difference between | and >?
| preserves newlines (great for code blocks, logs), output is multiline. > folds whitespace (great for long paragraphs), newlines become spaces. Suffixes: - strips the trailing newline (default keeps one); + keeps all trailing blank lines. Common: embedding nginx.conf into Kubernetes ConfigMap uses |.
How do anchors (&name) and references (*name) work?
YAML anchors let you reuse objects. `defaults: &default {timeout: 30, retries: 3}` defines an anchor; `service1: <<: *default` references and merges. JSON has no reference concept, so JSON→YAML expansion produces a repeated object. CI configs use this to reduce duplication.
When is YAML better than JSON?
YAML for human-edited config (Kubernetes, Docker Compose, GitHub Actions, Ansible), multiline strings, when comments matter. JSON for API data exchange (compact, fast parsing, native in every language). Do not use YAML for APIs (slow parsing, error-prone, comments not needed).

Use cases

  • Kubernetes manifest editing: convert deployment.yaml to JSON for validation, then back
  • GitHub Actions / GitLab CI: convert to JSON to see nesting clearly
  • Docker Compose: convert docker-compose.yml to JSON for jq processing
  • Spring Boot config: application.yml ↔ application.json for layer inspection
  • API doc: OpenAPI in YAML → JSON for tools to consume

Use cases

K8s manifests, CI configs, Docker Compose, Spring Boot configs, OpenAPI docs. Ops, backend, DevOps. Multi-document support, anchor expansion, multiline string handling are the differentiators.