How to use it
- Choose a direction. For YAML → JSON you can parse as YAML 1.2, the current specification, or YAML 1.1, which Python's PyYAML and some older tools use.
- Paste on the left; the result appears on the right as you type. Errors show the line and column.
- Read the yellow notes under the result: each one points to a value, with its line number, that means something different in another YAML version or whose spelling was silently changed.
- Use "Convert the result back" to round-trip and check that nothing changed.
Where YAML goes wrong
YAML 1.1 versus 1.2
Two versions of YAML are in wide use. YAML 1.2, published in 2009, set out to make YAML a strict superset of JSON and removed many problematic implicit typing rules. Under its core schema only true and false (in a few capitalisations) are booleans when unquoted, whereas the YAML 1.1 boolean type also includes yes, no, on, off, y and n. PyYAML states that it implements YAML 1.1. So COUNTRY: no is the string "no" in 1.2 and false in 1.1 — the so-called Norway problem, because Norway's country code is NO.
Numbers: 0755, 22:22, 1.10
In the YAML 1.1 integer rules, a leading 0 means octal and colon-separated digits mean base 60 (intended for times and angles). mode: 0755 is 493 in 1.1 and decimal 755 in 1.2 — neither is the text "0755" you probably meant — and an unquoted Docker Compose port mapping 22:22 becomes 22 × 60 + 22 = 1342 in 1.1. A trap in both versions: the version number 1.10 is read as a decimal and becomes 1.1.
When parsing as 1.2, the tool checks every unquoted value and warns about each of these cases with its line number. The safe habit is to quote anything you mean as text.
Quotes added when converting JSON to YAML
When turning JSON into YAML, the tool decides quoting by the stricter 1.1 rules, so "no", "on", "0755", "22:22" and "1.10" are all quoted — even a key named n, which means false in 1.1. The YAML it writes reads back to the original JSON whether the reader uses 1.1 or 1.2. Multi-line strings use the | block style for readability.
Precision and safety
Integers are read with arbitrary precision, so 12345678901234567890 does not turn into 12345678901234567000. Anchors and aliases (&base, *base) are expanded, with a limit on the number of aliases to guard against "billion laughs" inputs that expand to enormous size. Duplicate keys are reported as an error instead of one being silently kept.
Examples
| YAML | Read as 1.2 | Read as 1.1 |
|---|---|---|
| country: no | "no" (string) | false |
| on: 1 | key "on" | key becomes "true" |
| mode: 0755 | 755 | 493 |
| port: 22:22 | "22:22" (string) | 1342 |
| version: 1.10 | 1.1 | 1.1 |
| country: "no" | "no" | "no" |
The other way round, the JSON {"country": "no", "mode": "0755", "v": "1.10"} becomes country: "no", mode: "0755" and v: "1.10" — all three quoted, so every parser reads strings back.
Limits
- YAML comments are lost when converting to JSON, which has no comments.
- JSON to YAML keeps key order but cannot restore comments, anchors or quoting style from an earlier YAML file.
- When parsing as YAML 1.1, date-like values become timestamps and are written as ISO 8601 strings; with 1.2 they stay as written.
- Custom tags, such as !Ref and !Sub in AWS CloudFormation templates, are dropped and only the value is kept: !Ref MyBucket becomes "MyBucket". Use the template's own tooling for those files.
Frequently asked questions
Why did no become false?
Under YAML 1.1 rules yes, no, on and off are booleans, and tools such as PyYAML follow them. Quote the value: "no".
Why did the file mode 0755 change?
YAML 1.1 reads a leading 0 as octal (493); YAML 1.2 reads it as decimal (755). Write "0755" or 0o755.
Why should Docker Compose ports be quoted?
Unquoted 22:22 is the base-60 number 1342 in YAML 1.1. "22:22" is always text.
Are YAML comments kept?
No. JSON has no comments.
Is my config uploaded?
No. Parsing and conversion happen in your browser.