Why is my country code NO in quotes?

Because bare `NO` is the string `NO` to a YAML 1.2 reader and the boolean **false** to a YAML 1.1 one — and PyYAML, which a very large share of the world uses, implements 1.1. Here the value arrives as a JSON string, so we know what it is; quoting is the only writing that keeps it one.

Will my 20-digit ID survive?

Yes. The number is read as the text it is, so `12345678901234567890` comes out with all twenty digits. That is not free: `JSON.parse` would have rounded it to `12345678901234567000` first, which is how most converters lose it.

Can I get comments or anchors in the output?

No, and nothing could. JSON has neither, so there is nothing to carry across — a converter cannot invent a comment that was never written. If you need a documented YAML file, write the comments after converting, and keep the YAML as the source from then on.

JSON to YAML — Ready for Your Config File

Convert JSON to YAML. Indentation you choose, ambiguous values quoted, and a result that pastes straight into a Compose or CI file.

Instant Private Zero cookies

Indentation

Swap: YAML → JSON

JSON input

YAML output

What this tool does

YAML is a superset of JSON, so the mapping is direct: objects become mappings, arrays become sequences, and every scalar keeps its type.

{ "name": "Ada", "tags": ["math", "engine"], "active": true }

name: Ada
tags:
  - math
  - engine
active: true

Quoted where it would otherwise change meaning

{ "country": "NO", "flag": "yes", "at": "12:30" }

country: "NO"
flag: "yes"
at: "12:30"

Written bare, those three would be read as false, true and 750 by any YAML 1.1 parser — which is what PyYAML implements, and PyYAML is what a very large share of the world reads YAML with. It is called the Norway problem, after the country code that keeps turning into a boolean.

Here the value arrives from JSON as a string, so there is no ambiguity about what it is. Quoting it is the only writing that keeps it a string for every reader. Real booleans stay bare: true is true.

Long identifiers keep their digits

{ "id": 12345678901234567890 }

comes out with all twenty digits. Most converters parse JSON into a JavaScript value first, which sends every number through a double-precision float and rounds anything past about fifteen digits — quietly. The number is read here as the text it is.

Multi-line strings become block scalars

A string containing newlines is written in YAML’s readable block form rather than with \n escapes:

description: |-
  first line
  second line

What cannot come across

Comments and anchors. JSON has neither, so there is nothing to carry. A converter that offered to add them would be inventing your file’s documentation, and that is a job for a person.

Private by design

Everything runs locally in your browser with JavaScript. Your data is never uploaded, which makes the tool safe for sensitive content, and it keeps working offline.

Frequently asked questions

Why is my country code NO in quotes?: Because bare `NO` is the string `NO` to a YAML 1.2 reader and the boolean **false** to a YAML 1.1 one — and PyYAML, which a very large share of the world uses, implements 1.1. Here the value arrives as a JSON string, so we know what it is; quoting is the only writing that keeps it one.
Will my 20-digit ID survive?: Yes. The number is read as the text it is, so `12345678901234567890` comes out with all twenty digits. That is not free: `JSON.parse` would have rounded it to `12345678901234567000` first, which is how most converters lose it.
Can I get comments or anchors in the output?: No, and nothing could. JSON has neither, so there is nothing to carry across — a converter cannot invent a comment that was never written. If you need a documented YAML file, write the comments after converting, and keep the YAML as the source from then on.