JSON to YAML Converter

Indent

Converted output will appear here

Paste JSON on the left or load a sample

READY
LN 1, COL 10 CHARS

About the JSON/YAML Converter

The JSON / YAML Converter swaps between the two formats bidirectionally — RFC 8259 JSON in, YAML 1.2.2 out, or vice versa — entirely in your browser via js-yaml. Anchors (`&name`) and aliases (`*name`) are preserved on the YAML side; multi-document YAML (`---` separators) is supported; the converter handles the YAML 1.1 vs 1.2 boolean parsing differences (the famous "Norway problem") explicitly. Use it to translate Kubernetes manifests, GitHub Actions workflows, OpenAPI specs, and Helm values between the format your tools expect and the format your humans want to read. Documents stay in your tab — production manifests with cluster-internal hostnames are safe to paste.

Updated: May 8, 2026

Related Tools

JSON ViewerValidate, format, and explore the JSON side after conversion.Try it Diff CheckerCompare two YAML manifests before and after a Helm template render.Try it Regex TesterBuild patterns against extracted YAML keys / values.Try it SQL SuiteFormat SQL queries embedded in YAML configmaps and Kubernetes secrets.Try it JWT DecoderDecode JWTs found in YAML auth-config snippets.Try it

How to use the converter

  • Paste your JSON or YAML into the input area. The format is auto-detected by leading character (`{` / `[` for JSON, otherwise YAML).
  • Click the direction toggle to flip between JSON → YAML and YAML → JSON. The output panel updates live.
  • For YAML output, you can choose 2-space or 4-space indentation and toggle whether to emit anchors / aliases verbatim or expand them.
  • For JSON output, you can pretty-print or minify; comments from the YAML source are dropped (JSON has no equivalent).
  • Multi-document YAML (with `---` separators) becomes a JSON array of documents on the JSON side; conversely, a JSON array can be re-emitted as multi-document YAML if you check that option.

Common use cases

  • Kubernetes manifest editing. Helm-rendered manifests are typically YAML; if you need to inline-edit one in a JSON-aware tool (jq, JSON Schema validator), convert here, edit, and convert back.
  • GitHub Actions / GitLab CI workflows. Workflow files are YAML; pasting an example from documentation into a JSON-driven config-as-code system requires a format swap.
  • OpenAPI / Swagger specs. Many spec authors write in YAML for human readability; tooling sometimes wants JSON. Round-tripping preserves structure.
  • Helm values translation. `values.yaml` is the canonical Helm input; some downstream tooling consumes JSON. The converter keeps the structure identical.
  • JSON Schema with YAML support. JSON Schema specs allow YAML representations; converting between the two during authoring is the most common workflow.

Privacy and security

Conversion uses js-yaml (parse + stringify) and the native `JSON.parse` / `JSON.stringify`. Both libraries run inside your browser tab; no network call is made. Pasted documents — including production manifests with internal hostnames, secrets pulled from a config sync, or Helm values containing API keys — never leave the page. URL state is not auto-synced.

Tips and pitfalls

  • YAML 1.1 vs 1.2 boolean parsing — the Norway problem. In YAML 1.1, the strings `yes`, `no`, `on`, `off`, `True`, `False`, and the country code `NO` (Norway) all parse as booleans. YAML 1.2 dropped these to align with JSON. js-yaml uses 1.2 semantics by default; if your input was authored under a 1.1-targeting tool (some older Ansible, some Symfony YAML), set the schema to 1.1 explicitly.
  • Anchors and aliases. YAML supports `&name` (define) and `*name` (reference) for sharing structure across the document. The converter preserves them on the YAML side; on the JSON side they are resolved (each reference becomes its own copy of the structure).
  • Comments are lost converting to JSON. JSON has no comment syntax in the spec. YAML → JSON drops every `#`-comment; reverse direction cannot recover them. If comments matter, edit in YAML.
  • Indentation matters in YAML. A 2-space-vs-4-space mismatch within the same document is a parse error. The converter normalizes to your chosen output indent.
  • Multi-document YAML. The `---` separator marks document boundaries; the converter emits a JSON array on conversion. If your downstream tool expects only the first document, peel off the array element manually.

Frequently Asked Questions

Does the converter support YAML 1.2?
Yes — js-yaml uses YAML 1.2 semantics by default. The 1.2 spec aligns boolean parsing with JSON (only `true` / `false`), drops the implicit `yes` / `no` / `on` / `off` booleans, and unifies the binary / sexagesimal numeric forms. For 1.1-targeting input, an explicit schema toggle is available.
Are anchors and aliases preserved?
On round-trip YAML → YAML: yes. On YAML → JSON: aliases are resolved to inline copies (JSON has no equivalent of references). On JSON → YAML: nothing to preserve, but the emitter can opt to emit anchors when the same object reference appears multiple times.
Are comments preserved?
Within YAML: yes, on a best-effort basis (js-yaml preserves leading and trailing comments around mappings). YAML → JSON loses all comments because JSON does not have a comment syntax. JSON → YAML cannot generate comments out of nothing.
Is multi-document YAML supported?
Yes. Documents separated by `---` are parsed into a JavaScript array; on conversion to JSON they become a JSON array. On JSON → YAML, an input JSON array can be emitted either as a single YAML sequence or as a multi-document YAML stream — choose the format your downstream tool expects.
What is the Norway problem?
In YAML 1.1, the country code `NO` (in country lists, ISO codes, etc.) parses as the boolean `false` because `no` is one of the implicit boolean literals. The fix in YAML 1.2 was to drop the `yes` / `no` / `on` / `off` literals — only `true` and `false` remain. js-yaml 4.x defaults to 1.2 semantics, so the Norway problem is fixed unless you opt into 1.1.
Is round-trip conversion safe?
Round-tripping JSON → YAML → JSON is lossless (except for key ordering, which is preserved within objects but is not part of the JSON spec). YAML → JSON → YAML loses comments and may rearrange anchors. For preservation-critical workflows, edit in YAML directly.
When should I pick YAML over JSON for a new project?
When the file will be primarily read or edited by humans — Kubernetes manifests, CI/CD workflows, application configs. JSON is better for machine-to-machine transport (APIs, log records, structured events) where strict parsing and minimal whitespace matter.
When should I pick JSON over YAML?
When the document is generated by a program and consumed by another program. JSON has stricter, simpler semantics (no implicit type coercion, no significant indentation, no anchors/aliases) which makes parsing and validation predictable across language ecosystems.
Where can I read the standards?
RFC 8259 is the JSON spec (very short, very strict). YAML 1.2.2 is the current YAML spec (much longer; the type system is the bulk of it). The js-yaml repository on GitHub has a thorough README covering schema differences and edge cases.