JSON to YAML Converter

Paste valid JSON — an object, array, scalar, API response, or full Kubernetes manifest — and the converter emits the YAML equivalent in real time. The conversion runs entirely in your browser using the native JSON.parse for input validation (per ECMA-404 / RFC 8259), then walks the parsed tree emitting YAML 1.2.2 syntax. 2-space indentation is the default — the de-facto standard across Kubernetes, Ansible, GitHub Actions, and Docker Compose. Switch to 4-space indent if your codebase requires it. Output is ready to paste into a `.yaml` file or pipe to `kubectl apply -f -`. The right-hand pane shows live byte and line counts so you can sanity-check size before committing.

Step 1: Paste your JSON into the editor. The converter validates as you type — invalid JSON shows the exact parser error with line and column. Step 2: The YAML output appears live in the right pane. No button click needed; every keystroke re-renders. Step 3: Click Copy (clipboard) or Download (`.yaml` file). For programmatic workflows, the same logic is exposed via the `/api/calculate` endpoint — POST JSON to it and receive the YAML in the response body. Round-trip safety: convert YAML back to JSON with the sister YAML to JSON Converter; the data model is preserved exactly (comments and anchors are YAML-only and don't survive the round trip).

JSON and YAML represent the same data model — maps (objects), sequences (arrays), and scalars (string/number/bool/null) — but with very different surface syntax. JSON is brace-and-quote heavy: every key gets `"`, every map gets `{}`, every array gets `[]`, and every separator is explicit (`:` and `,`). YAML is indentation-driven: nesting is implied by 2-space indent, sequences use `- ` prefix, and most strings don't need quotes. JSON parses 5–10× faster across all major language runtimes, has zero ambiguity, and is the right choice for APIs, message queues, log streams, and storage formats. YAML supports comments (`#`), anchors and aliases for re-use (`&name` / `*name`), multi-document streams (`---`), and explicit type tags (`!!str`, `!!int`) — strengths that make it the right choice for source-controlled configs, CI/CD pipelines, infrastructure-as-code, and Kubernetes manifests. Pick JSON for machines, YAML for humans, and convert between them at the boundary.

Deep nesting is where JSON-to-YAML conversion earns its keep — tracking braces and indentation by hand at 5+ levels is error-prone. The converter walks the parsed JSON tree recursively. For each map (object), keys are emitted in source order with `key: value` syntax; nested values are indented by 2 more spaces. For each sequence (array), items use `- ` prefix; nested objects under a `-` start on the same line as the dash and inherit the next indent level. Mixed structures — arrays of objects, objects containing arrays of objects, recursively — all render correctly. Maximum depth is bounded only by your browser's call stack (~10,000+ frames in modern browsers, far beyond any realistic config). Test with your own fixtures: parse the YAML output back to JSON and assert structural equality with the input.

Kubernetes manifests are the most common use case for this converter. Many tools (kubectl, Lens, k9s, Helm) emit JSON via `-o json` flags; the canonical source-of-truth format committed to Git is YAML. Paste the JSON output of `kubectl get deployment -o json` and the converter produces a clean manifest ready to commit. apiVersion, kind, metadata, and spec hierarchies preserve exact field ordering. For Helm chart values, paste your JSON values and drop the YAML into `values.yaml` — Helm templates pick it up unchanged. For Kustomize overlays, convert your patch object and add to the `patchesStrategicMerge` list. Validate the output with `kubectl apply --dry-run=client -f file.yaml` before committing — it catches schema-level issues that YAML syntax validation alone would miss.

Docker Compose files are pure YAML conforming to the Compose Specification (compose-spec.io). When you have programmatic JSON output — from a config generator, a previous Compose v2 export, or a templating script — convert it here and paste into `docker-compose.yaml`. Top-level keys (`services`, `networks`, `volumes`, `configs`, `secrets`) and their nested specs (image, ports, environment, depends_on, healthcheck) all convert correctly. Watch for ports: shorthand strings like `"8080:80"` must stay quoted in YAML to prevent parsing as a sexagesimal number — the converter handles this automatically. Validate with `docker compose config` before `docker compose up`; it parses, merges multiple files, and prints the resolved config exactly as the engine will run it.

YAML's indentation rules are strict: 2 spaces per level (4 also valid but rare), tabs are forbidden, and sibling keys must align exactly. Sequences (`- item`) and maps (`key: value`) can nest freely. Multi-line strings come in two flavors: literal blocks (`|`) preserve every newline; folded blocks (`>`) join lines with spaces (paragraph-style). Anchors (`&name`) and aliases (`*name`) let you define a YAML node once and reuse it elsewhere — common in Compose files for shared service templates. Explicit type tags (`!!str`, `!!int`, `!!bool`, `!!null`) override YAML's auto-typing when you need a string that looks like a number, or vice versa. The converter quotes ambiguous strings automatically: `"yes"`, `"no"`, `"null"`, `"~"`, numeric-looking values like `"01234"`, and any string containing YAML special characters (`:`, `#`, `-`, `&`, `*`, `!`, `|`, `>`, `'`, `"`, `%`, `@`).

Six errors account for 95% of broken YAML in the wild. (1) Tabs anywhere — even one tab character breaks parsing. Configure your editor to insert spaces. (2) Inconsistent indentation — a sibling key off by one column is a parse error. (3) Missing space after `:` — `key:value` is invalid; `key: value` is correct. (4) Unquoted strings that look like booleans (`yes`, `no`, `on`, `off`) — get coerced to true/false in YAML 1.1 (older parsers). YAML 1.2 narrowed booleans to `true`/`false` only, but defensive quoting is still wise. (5) Numeric strings without quotes — `01234` becomes integer 1234, losing the leading zero. (6) Missing space after `-` — `-item` is a string starting with a dash; `- item` is a sequence entry. Validate with `yamllint`, the YAML extension in VS Code, or domain-specific validators (`kubectl --dry-run`, `docker compose config`, `ansible-playbook --syntax-check`).

API workflows benefit from JSON-to-YAML in two places. First, OpenAPI 3.x specs are commonly authored in YAML (more readable for path/parameter trees) but exported as JSON for tooling — convert in either direction as your editing flow requires. The converter preserves required fields, schema definitions, $ref pointers, and example bodies. Second, when documenting an API, paste a sample JSON response and present the YAML version in your docs — easier for readers to scan deeply nested response bodies. For Swagger UI integration, both `swagger.yaml` and `swagger.json` are accepted; many teams keep YAML in source control and emit JSON at build time. Round-trip safety holds for OpenAPI specs since they don't use comments or anchors in canonical form.

Almost every modern CI/CD platform uses YAML for pipeline definitions: GitHub Actions (`.github/workflows/*.yaml`), GitLab CI (`.gitlab-ci.yml`), CircleCI (`.circleci/config.yml`), Travis (`.travis.yml`), Drone, Concourse, Argo Workflows, Tekton. When you have a JSON config — from a generator, a previous version control export, or a programmatic builder — paste here and emit YAML. Ansible playbooks specifically lean heavily on YAML's list-of-tasks structure with anchors for reused blocks; the converter outputs sequences cleanly so you can paste under `tasks:` without further edits. For GitHub Actions, the trickiest part is `if:` conditions and matrix strategies — keep the converted YAML, then add comments explaining intent (a YAML-only feature you'll lose if you go back to JSON).

Five edge cases break naive converters. (1) Comments: JSON has none, YAML supports `#`. Round-tripping JSON → YAML → JSON is lossless, but YAML → JSON → YAML drops every comment. Keep YAML as your source of truth when comments matter. (2) Boolean coercion: legacy YAML 1.1 parsers treat `yes`/`no`/`on`/`off` as booleans. Modern parsers (1.2.2) only treat `true`/`false` that way, but defensive quoting prevents surprises. (3) Null: JSON `null` maps to YAML `null`, `~`, or empty value. The converter emits `null` for clarity; some tools prefer empty (`key:`) but it can be ambiguous with empty strings. (4) Numeric strings: `"01234"` (a US ZIP code) loses the leading zero if unquoted in YAML — the converter quotes it. (5) Floats with trailing zeros: `1.50` round-trips as `1.5` because both JSON and YAML use canonical numeric representation. If trailing zeros matter (currency, version strings), serialize as strings.

Type mapping at a glance: JSON object → YAML map (block style); JSON array → YAML sequence (`-` items); JSON string → YAML string (auto-quoted when ambiguous); JSON number → YAML scalar with same numeric value; JSON true/false → YAML true/false; JSON null → YAML null. Style choices: prefer block style (multi-line, indented) for readability over flow style (`{key: value, ...}` JSON-like compact); use 2-space indent always; emit keys in source order (matches JSON's behavior). Round-trip tips: (1) JSON → YAML → JSON is lossless. (2) YAML → JSON drops comments, anchors (expanded), explicit tags, multi-document streams. (3) Always quote strings that look like booleans, null, or numbers. (4) Test your output with the actual tool that consumes it (kubectl, docker compose, ansible-playbook) — these have stricter validation than generic YAML parsers. (5) Keep both versions in source control if your team uses both formats; treat one as canonical (typically YAML for configs, JSON for APIs) and regenerate the other on build.