JSON to YAML & YAML to JSON Converter
A JSON to YAML converter that runs both ways in your browser, covering implicit typing: why 1.20 becomes 1.2 and unquoted NO can become false.
YAML Output (Kubernetes / Docker Ready)
What JSON to YAML & YAML to JSON Converter Does
YAML 1.2 is a superset of JSON: any valid JSON document is also valid YAML, and a YAML parser reads it unchanged. The conversion that matters is the other direction, turning JSON's explicit punctuation into YAML's indentation-based structure, which is what this tool does.
YAML is more readable, which is why Kubernetes manifests, GitHub Actions workflows, Docker Compose files and OpenAPI specifications use it. It is also considerably more dangerous, because YAML guesses types from unquoted text and JSON never does.
That guessing is the source of every surprising YAML bug. A value that looks like a number, a date, a boolean or a time gets converted to one, and the string you wrote is gone.
How to Use JSON to YAML & YAML to JSON Converter
- Paste your JSON code into the text area
- View formatted YAML output in real-time
- Click Copy YAML for your Kubernetes or GitHub Actions configuration
How JSON to YAML & YAML to JSON Converter Works
JSON to YAML block style
object → key: value lines · nested object or list → indent two spaces · list item → "- " · string → always double-quoted with JSON escaping · number, true, false, null → written as-is
- double-quoted strings
- Every string is quoted, using JSON's escapes (\" \\ \n \uXXXX), which YAML accepts inside double quotes. That stops a reader from re-typing "no", "1.10" or "08" as a boolean or number.
- keys
- Written bare when they are plain names. Keys that YAML 1.1 reads as booleans or null (on, off, yes, no, y, n, true, false, null, ~) and keys with spaces or punctuation are quoted.
- lists of objects
- The first key sits on the dash line (- port: 80) and the rest align under it, the style Kubernetes and most CI files use.
- empty values
- An empty object or list is written as {} or [] so it does not turn into null.
Worked example
{"name":"web","on":{"push":null},"ports":[{"port":80,"protocol":"TCP"}],"note":"say \"hi\"","version":"1.10"}
- name: "web" (string, quoted)
- "on": is quoted, because unquoted it loads as the boolean true in YAML 1.1 parsers such as PyYAML
- ports: becomes a list; its object starts on the dash line: - port: 80, then protocol: "TCP" aligned beneath
- note: "say \"hi\"" keeps its inner quotes escaped
- version: "1.10" stays a string; unquoted, it would load as the number 1.1
Result: name: "web" / "on": / push: null (indented) / ports: / - port: 80 / protocol: "TCP" / note: "say \"hi\"" / version: "1.10". A YAML parser reads it back to exactly the original JSON.
Implicit Typing — What Unquoted Values Become
Verified locally against a YAML 1.2 core-schema parser. Results marked (1.1) follow the older schema still used by several widely-deployed parsers.
| You write | YAML 1.2 core | YAML 1.1 schema | Problem |
|---|---|---|---|
| version: 1.20 | number 1.2 | number 1.2 | Trailing zero lost from a version string — verified |
| octal: 0755 | number 755 | number 493 | A file mode read as decimal, or as octal, depending on parser |
| country: no | string "no" | boolean false | The "Norway problem" — country code NO becomes false |
| answer: yes | string "yes" | boolean true | Same class of bug |
| flag: off | string "off" | boolean false | Same class of bug |
| time: 12:30 | string "12:30" | number 750 (sexagesimal) | A time read as base-60 |
| value: ~ | null | null | Tilde is null, not a tilde character |
| empty: | null | null | An empty value is null, not an empty string |
JSON and YAML Compared
| JSON | YAML | |
|---|---|---|
| Comments | Not supported | # to end of line |
| Structure | Braces and brackets | Indentation (spaces only, never tabs) |
| Typing | Explicit — quoted is a string | Implicit — inferred from the text |
| Multi-line strings | Escaped \n only | Literal (|) and folded (>) blocks |
| Anchors and references | None | &anchor and *reference for reuse |
| Multiple documents | One per file | Separated by --- |
| Parsing risk | Low | Higher — some loaders can instantiate objects |
Where Each Is Used
| Format | Typical use |
|---|---|
| YAML | Kubernetes, GitHub Actions, Docker Compose, Ansible, OpenAPI specs, CI config |
| JSON | APIs, package manifests, browser storage, machine-to-machine data |
| Rule of thumb | YAML where humans write and edit it; JSON where machines exchange it |
How to Read Your Result
Quote anything that must stay a string
Version numbers, country codes, phone numbers, file modes, times and anything with leading zeros should be quoted in YAML. "1.20" stays a string; 1.20 becomes the number 1.2 and your version comparison breaks. This single habit prevents most YAML data bugs.
Tabs are a syntax error
YAML forbids tab characters for indentation, unconditionally. An editor configured to insert tabs will produce files that fail to parse with an error pointing at a line that looks perfectly fine. Configure spaces for .yml and .yaml files.
Use safe loading
Some YAML libraries can construct arbitrary objects from tags in the document, which turns loading an untrusted file into code execution. Python's yaml.load was the well-known example and now defaults to safe behavior. Use the safe loader explicitly for anything you did not write.
JSON is already valid YAML
Confirmed by round-tripping: a YAML parser reads a JSON document unchanged. That means you can paste JSON into a YAML file and it will parse. This is useful when embedding a compact structure inside an otherwise indented document, though it reads poorly.
Limitations & Accuracy Notes
- YAML comments cannot survive a conversion from JSON, because JSON has no comments to carry. Converting YAML to JSON and back loses every comment in the file.
- This tool converts JSON to YAML only. Its output never uses anchors or aliases, so a structure repeated in the JSON is written out in full each time. In the other direction, converting YAML to JSON expands any anchors, and the deduplication the original author intended is lost.
- Implicit typing behavior differs between YAML 1.1 and 1.2 and between parsers. The table above reports a 1.2 core-schema parser, verified locally; check your own consumer if the distinction matters.
- Key order is preserved in the output but has no formal meaning in either format.
- This handles data structures. YAML's more exotic features, such as custom tags, complex mapping keys and multi-document streams, may not round-trip.
Frequently Asked Questions
Why is YAML used over JSON in DevOps?
YAML uses clean indentation without curly braces or double quotes, making it significantly more human-readable for complex deployment configurations.
Is the conversion performed securely in browser?
Yes, 100% of the conversion runs locally in your browser memory with zero data sent to external servers.
Is YAML a strict superset of JSON?
Nearly. Most JSON is valid YAML since YAML supports flow-style mappings and sequences using {} and [], but subtle edge cases can behave differently, so always validate converted output for critical use cases.
Why is YAML sensitive to indentation?
YAML uses indentation levels, spaces only, never tabs, to represent nested structure instead of explicit braces or brackets, so inconsistent indentation is a common source of parsing errors.
Is YAML a superset of JSON?
YAML 1.2 is, so valid JSON is valid YAML and can be pasted straight in. The reverse is not true: YAML has anchors, comments and multiple documents per file that JSON cannot express.
What is the Norway problem?
In YAML 1.1, unquoted NO parses as the boolean false, so a list of country codes silently turns Norway into false. ON, OFF, YES and TRUE behave similarly. YAML 1.2 fixed it, but many parsers still use 1.1 semantics, which is why quoting ambiguous strings matters.
Why does my YAML break after editing?
Almost always indentation. YAML uses it structurally and forbids tabs entirely, so a tab inserted by an editor produces a parse error that is invisible on screen. Configure the editor to expand tabs in YAML files.
Should I quote strings in YAML?
Quote anything that could be read as another type: version numbers like 1.10 that would become floats, values starting with a zero, and anything that resembles a boolean or a date. Unquoted looks cleaner and is where the surprises live.
Why use YAML over JSON for configuration?
Comments, mainly. JSON has none, which is a serious limitation in a config file. YAML is also less punctuation-heavy for humans to edit. For machine-to-machine data interchange JSON remains the better choice.
Is my data uploaded?
No. The conversion runs in your browser.
References & Further Reading
- YAML 1.2 Specification — The current spec, including the core schema and its resolution rules
- RFC 8259 — The JSON Data Interchange Format — The source format