YAML to JSON Converter

Paste valid YAML — a Kubernetes manifest, Compose file, Ansible playbook, OpenAPI spec, or any YAML 1.2 document — and the converter emits the JSON equivalent in real time.

The conversion runs entirely in your browser using a YAML 1.2 parser, then walks the parsed tree emitting JSON via JSON.stringify (per ECMA-404 / RFC 8259).

Pick your output style:

• 2-space (default, human-readable)
• 4-space (some enterprise codebases)
• minified (APIs, network payloads)

Output is ready to paste into a `.json` file or pipe to `kubectl apply -f -` (which accepts JSON via stdin). The right-hand pane shows live byte and line counts so you can sanity-check size before committing.

Converting YAML to JSON takes three steps:

• Step 1: Paste your YAML into the editor. The parser validates as you type — invalid YAML shows the exact parse error with line and column.
• Step 2: The JSON output appears live in the right pane. No button click needed; every keystroke re-parses.
• Step 3: Click Copy (clipboard) or Download (`.json` file).

For programmatic workflows, the same logic is exposed via the `/api/calculate` endpoint — POST YAML to it and receive the JSON in the response body.

Round-trip safety: convert JSON back to YAML with the sister JSON to YAML Converter; the data model is preserved exactly (comments and anchors are YAML-only and don't survive the round trip).

YAML and JSON represent the same data model — maps (objects), sequences (arrays), and scalars (string/number/bool/null) — but with very different surface syntax.

YAML is indentation-driven: nesting is implied by 2-space indent, sequences use `- ` prefix, and most strings don't need quotes. JSON is brace-and-quote heavy: every key gets `"`, every map gets `{}`, every array gets `[]`, and every separator is explicit (`:` and `,`).

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. JSON parses 5–10× faster, has zero ambiguity, and is the right choice for APIs and storage.

Convert at the boundary: YAML for humans, JSON for machines.

Deep nesting is where YAML-to-JSON conversion shines — tracking indentation by hand at 5+ levels is error-prone. The converter walks the parsed YAML tree recursively.

• For each block map, keys are emitted in source order with `"key": value` JSON syntax; nested values get `{...}` braces.
• For each block sequence, items emit as `[...]` JSON arrays; nested objects under a `-` become `{...}` array elements.

Mixed structures — sequences of maps, maps containing sequences of maps, recursively — all convert 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 JSON output back to YAML and assert structural equality with the input.

YAML's loose type inference is the source of many bugs in real-world configs. YAML 1.2 (the modern standard, target of this converter) narrowed the rules to be safer.

• Booleans: ONLY `true` and `false` (case-insensitive). YAML 1.1 also treated `yes`/`no`/`on`/`off` as booleans, which famously broke configs containing Norway's country code `NO` (silently converted to `false`) — the 'Norway problem'. Most modern parsers (js-yaml, PyYAML 6+, Snakeyaml) default to 1.2 behavior.
• Null: `null`, `~`, or empty value all become JSON null.
• Numbers: digit patterns matching JSON's integer/float syntax become JSON numbers; everything else stays a string.
• Strings: quoted values always stay strings; numeric strings like ZIP codes (`"01234"`) and calendar dates need quoting in YAML to survive conversion — when a config holds a date you first worked out with a date calculator, wrap it in quotes so the parser keeps it verbatim instead of coercing it.

The converter respects these rules strictly.

Kubernetes accepts both YAML and JSON via its API server, kubectl, and client libraries. Most teams keep YAML in source control (PRs are easier to review) but feed JSON to programmatic tooling — custom controllers, GitOps pipelines, Helm post-renderers, or webhooks.

Paste your manifest (Pod, Deployment, Service, ConfigMap, etc.) and copy the JSON output. The converter preserves apiVersion, kind, metadata, and spec hierarchies in field-order — Kubernetes expects camelCase keys throughout, so if you're porting fields from a snake_case source a case converter fixes the naming before you paste.

Validate with `kubectl apply --dry-run=client -f -` (which accepts JSON on stdin) before committing. For multi-resource manifests separated by `---`, split into individual documents first — JSON has no multi-document syntax.

Three high-volume use cases beyond Kubernetes:

• Docker Compose: paste a `docker-compose.yaml` and copy JSON for tools like Kompose (migrates Compose to K8s), custom orchestrators, or programmatic config transformations.
• Ansible: convert playbooks to JSON for documentation tooling, custom CI integrations, or REST/GraphQL APIs that store playbook definitions.
• CI/CD pipelines: GitHub Actions (`.github/workflows/*.yml`), GitLab CI (`.gitlab-ci.yml`), CircleCI, Travis — convert any of these to JSON for analytics, programmatic edits, or audit-log archival. Their scheduled `cron` triggers are pinned to UTC, so a time zone converter keeps you from mis-reading when a pipeline actually fires in your local time.

Note: Jinja2 expressions (`{{ var }}`), Helm template syntax (`{{ .Values.x }}`), and similar templating remain as plain strings in JSON — they're not evaluated by the converter.

OpenAPI 3.x specs are commonly authored in YAML (more readable for path/parameter trees) but consumed as JSON by older tooling — legacy Swagger UI builds, certain enterprise API gateways, and some code generators.

Paste your `openapi.yaml` (or `swagger.yaml`) and download `openapi.json`. The converter preserves `$ref` pointers exactly (no resolution), schema definitions, response examples, and security schemes.

After conversion, validate with the official OpenAPI validator (Spectral CLI, openapi-cli, swagger-cli) to confirm schema compliance. Many teams keep YAML in source control and emit JSON at build time — both `swagger.yaml` and `swagger.json` are fully equivalent for API consumers.

Six errors account for 95% of YAML parse failures:

• Tabs anywhere in indentation — YAML forbids tabs entirely, even one tab character breaks parsing.
• Inconsistent indentation — sibling keys must align at the exact same column.
• Missing space after `:` in maps — `key:value` is invalid; `key: value` is correct.
• Missing space after `-` in sequences — `-item` is a string starting with dash; `- item` is a sequence entry.
• Unquoted special characters at the start of a value — `@`, `` ` ``, `%`, `*`, `&` need quoting.
• Unsupported features in the converter: anchors (`&name`), aliases (`*name`), and multi-document streams (`---`) — for these, use a full YAML library like js-yaml, PyYAML, or `yq`.

The error message shows line and column where parsing failed.

Three YAML features have no direct JSON equivalent and need special handling:

• Anchors (`&name`) and aliases (`*name`) let YAML reference a node and reuse it elsewhere — common in Compose files for shared service templates and CloudFormation for shared parameters. JSON has no reference syntax, so the converter expands aliases inline (each alias becomes a full copy). The data is preserved but the JSON is larger and shared-reference structure is lost.
• Multi-document streams (`---` separator) represent multiple top-level values in one file — common for bundling Kubernetes resources. JSON has only single root values per document. Split the YAML into separate files first or wrap docs in a JSON array `[doc1, doc2, doc3]`.
• Comments (`#`) are YAML-only — they're stripped entirely during conversion. Keep YAML as source of truth if comments matter.

Five round-trip considerations every developer should know:

• Data model: YAML → JSON → YAML preserves keys, values, types, and nesting exactly. The data is identical going in and coming back out.
• Comments: lost forever — JSON has no comment syntax. Keep YAML as source of truth if you have inline docs.
• Anchors/aliases: expanded on the way to JSON, never recreated on the way back. The output YAML has duplicated content where the source had shared references.
• Key order: YAML preserves source order; the converter preserves it through to JSON; round-trip back to YAML keeps the same order.
• Type tags (`!!str`, `!!int`) — only emitted when needed for disambiguation. A string `"01234"` survives round-trip because the JSON keeps it quoted; an unquoted YAML `01234` parses as an integer and round-trips as the number 1234, losing the leading zero.

Quote ambiguous values defensively.

Type mapping at a glance:

• YAML map → JSON object
• YAML sequence → JSON array
• YAML scalar (per type inference) → JSON string/number/boolean/null
• YAML !!str tag → JSON string (forced)
• YAML null/~/empty → JSON null
• YAML true/false → JSON boolean
• YAML integer pattern → JSON integer
• YAML float pattern → JSON number

Tool comparison:

• this converter (browser, instant, no install, 95% of real YAML)
• `yq -o json` (CLI, large files, JSONPath queries)
• `js-yaml`/`PyYAML` (full library, anchors and multi-doc supported, programmatic use)

Best practices:

• Always quote ambiguous values (yes/no/on/off/null/numeric IDs) in YAML source.
• Use 2-space indent (the de-facto standard).
• Validate the JSON output against your downstream consumer's schema (JSON Schema, OpenAPI, K8s OpenAPI) — type errors surface here.
• Keep YAML as canonical source and regenerate JSON at build time when possible.