YAML ⇄ JSON Converter

YAML 1.2 is a superset of JSON, and this parser behaves that way: braces and brackets are YAML written in flow style. Paste a JSON document into the YAML to JSON direction, minified or pretty-printed, and it loads without complaint and comes back re-indented at two spaces, which makes that side a usable JSON tidier when you have nothing else to hand. The reverse does not hold — a YAML file using indentation instead of braces is not JSON, and pasting one into the JSON to YAML direction gives you a parse error from the browser rather than a conversion.

Anything that could be read as another type. Booleans are true and false in any capitalisation, so True and FALSE convert too. The words yes, no, on and off stay strings under YAML 1.2, but an older 1.1 parser turns them into booleans — the classic Norway problem, where a country code of NO becomes false somewhere downstream. Quote them anyway. Numbers deserve the same care: a version written 3.10 arrives as 3.1, and a leading zero is dropped, so 0755 becomes 755 and an account number written 0123456789 loses its first digit.

They cannot survive, because JSON has no comment syntax. The parser reads them and discards them, and nothing in the output marks where they were — which in most YAML files is where the reasons live, so it is often the majority of the human value in the document. The trap works the other way too: a config written in JSON with C-style comments, sometimes called JSONC, is not valid JSON and the JSON to YAML direction refuses it at the first slash. Strip those comments, or bring the file in through the YAML side, which accepts hash comments happily.

Anchors and aliases are resolved during parsing, not preserved. A map defined once and referred to in five places is written out five separate times, so the JSON is correct but longer, and the shared definition you were relying on for maintenance is gone. Merge keys deserve their own warning: the merge type is not part of the YAML 1.2 core set, so a line reading << followed by an alias is not merged into the surrounding map — the key << survives literally, holding the referenced map as its value. Check the output before assuming your defaults were applied.

Because tags outside the core set are not recognised, and the parser stops rather than guessing. A template containing !Ref or !GetAtt, or a document using the binary type, produces an unknown scalar tag message naming the line and column of the offending tag. That is the honest behaviour for a converter that does not know your schema: a tag is an instruction to build a value of some application-specific type, and there is no general JSON equivalent for one. To convert such a file, replace the tags with their long form first, or convert only the parts that avoid them.

Never for indentation — tab characters there are rejected outright, with the line and column named, and it is a common reason a hand-edited file fails. Set your editor to insert spaces for YAML and it stops happening. The worse case is the indentation mistake that does not fail: misalign the items of a list and they can be read as one plain scalar spread over several lines, so a two-item list arrives as a single joined string. Nothing errors, the output is quietly wrong, which is why it is worth reading the JSON rather than treating no red text as success.

Nothing is sent anywhere. What you type lives in the page as component state, the conversion runs in a memo that recomputes as you type, and the parsing is done by a library bundled into the JavaScript your browser already loaded — no upload, no request, no server route behind it. That is the reason to prefer a local converter for this format in particular: YAML is where deployment configs keep database passwords, API keys and connection strings, and pasting one into a remote service hands those over. Closing the tab is the whole of the cleanup.

Not always. Every number goes through JavaScript's double-precision arithmetic, which holds integers exactly only to sixteen or so digits. A twenty-digit identifier such as 12345678901234567890 comes back as 12345678901234567000, silently, with nothing to say the last digits were invented. Anything that is an identifier rather than a quantity should be quoted as a string in the YAML, which also protects it from the leading-zero problem. Two more values have no JSON spelling: infinity and not-a-number, written .inf and .nan, both convert to null, so their presence means the conversion changed the meaning.