JSON to YAML

Paste your JSON and get clean, readable YAML output instantly. Everything runs in your browser — nothing is sent to any server.

Paste your JSON to get started
Input
YAML

Frequently Asked Questions

Is JSON-to-YAML conversion always lossless?

Yes. YAML is a strict superset of JSON — every valid JSON document is also valid YAML. Converting JSON to YAML preserves all data types, values, nesting, and ordering. The reverse is not true: converting YAML to JSON loses comments, YAML anchors and aliases (& and *), multi-line block scalars, and YAML-specific type tags. If you round-trip (JSON → YAML → JSON), you get the original data back.

What is the 'Norway problem' and does it affect JSON-to-YAML conversion?

The Norway problem is a YAML gotcha where the bare string NO is parsed as boolean false by YAML 1.1 parsers (since no, off, on, yes, y, n are all boolean aliases in YAML 1.1). This caused the ISO country code for Norway to be misinterpreted in many systems. YAML 1.2 removed all boolean aliases except true and false. However, many libraries (PyYAML, Go's yaml.v2) still use a YAML 1.1 parser by default. A correct converter quotes strings like NO or YES to prevent reinterpretation.

When should I use YAML instead of JSON for configuration files?

YAML is preferred when humans write and maintain the file directly — it supports comments (#), is less visually noisy (no braces, brackets, or quotes for simple values), and is the standard for Kubernetes manifests, Docker Compose files, GitHub Actions, and Ansible playbooks. JSON is preferred when machines produce and consume the data: it has unambiguous syntax, broad library support, and no whitespace-sensitivity. JSON is also faster to parse. Rule of thumb: use YAML for configs humans touch, JSON for API payloads.

What YAML-only features are lost when going back from YAML to JSON?

YAML supports features with no JSON equivalent: comments (#), anchors and aliases (&anchor / *alias for referencing repeated structures), multi-line block scalars (| for literal, > for folded), complex keys (any YAML node as a key, not just strings), and custom type tags. The most useful in practice are anchors — they let you define a value once and reference it multiple times in a config file, avoiding repetition. All of these are permanently lost on conversion to JSON.

How does a YAML converter handle JSON null, boolean, and numeric types?

JSON null maps to YAML null or ~. JSON true/false map to YAML true/false. Integers and floats are preserved. The edge cases arise with YAML's implicit type coercion: the string "1.0" in JSON (a string, because it is quoted) must remain a quoted string in YAML — if the quotes are dropped, YAML parsers may interpret it as the float 1.0. A well-behaved converter preserves type intent by quoting strings that could be ambiguously parsed as scalars.