What Gets Lost Converting YAML to JSON and Back

Converting YAML to JSON loses comments, anchor and alias structure, original number spelling, and any digits past what a JavaScript number can hold. Reformatting YAML loses the same things, because a formatter has to parse the file into data and write it back out. Comments are the most visible casualty: a file starting with "# top" and a line ending "# inline" came back with both gone, leaving only name: app and port: 80. Anchors survive as anchors but get renamed. Big integers are rounded. The data your program reads is the same; the human layer around it is not. Treat any YAML you format or convert as a one-way trip unless you keep the original.

Comments are discarded the moment YAML is parsed, so no JSON conversion and no parse-and-dump formatter can keep them. JSON has no comment syntax, and the YAML library the Code Beautifier uses, js-yaml, builds plain data first and writes text second. In our test, a file with a header comment and an inline comment was reformatted to just the two key lines. The practical rule is simple: if the comments matter, such as a note on why a version is pinned, do not run that file through a beautifier and save over it. Use the formatter to check validity or to tidy a copy, and keep the commented original in version control.

In JSON, every alias becomes a full copy of the anchored data, and a merge key may not merge at all. We parsed a file with base: &b and dev: *b, prod: *b. As JSON, base, dev, and prod each held {"a":1,"b":2}. Dumped back to YAML, js-yaml 5.4.2 kept the sharing but renamed it: base: &ref_0 with dev: *ref_0, so your anchor name b is gone. Merge keys behaved differently than many guides say. With dev: containing <<: *b and b: 3, js-yaml 5.4.2 did not merge. It produced dev: {"<<": {a:1, b:2}, b:3}, a literal key named <<. Parsers that implement the YAML 1.1 merge key would give different data for the same file. If your config relies on <<, check your own parser before trusting any converter.

Any integer beyond 9,007,199,254,740,991 is rounded, in both YAML and JSON, as soon as a JavaScript tool reads it. We tested 12345678901234567890 and 9007199254740993. JSON.parse then JSON.stringify returned 12345678901234567000 and 9007199254740992. The YAML route through js-yaml gave the same two values, and the dumped YAML printed the same rounded numbers. The cause is that JavaScript stores numbers as 64-bit floats, which hold about 15 to 17 significant digits. The digits are not hidden, they are replaced. For IDs, order numbers, or snowflake IDs, write the value as a quoted string in YAML and it passes through untouched.

With js-yaml 5.4.2, most look-alike values stayed as strings or became plain decimals, which differs from the YAML 1.1 behavior many people remember. We loaded a file and observed: no, yes, and on stayed the strings "no", "yes", and "on", and were re-emitted in quotes. 0o14 became 12, 0x1F became 31, and 010 became 10 (decimal, not octal 8). 1e3 became 1000 and 1.0 became 1, so the trailing .0 vanishes. The date 2026-10-02 stayed the string "2026-10-02", not a Date object, and was re-emitted quoted. Other parsers may read these same lines as booleans, octal numbers, or timestamps, so results can differ by tool. Quote anything ambiguous.

The Code Beautifier parses your YAML with js-yaml and writes it back with your chosen indent and no line folding. In the source, beautifying calls load then dump with lineWidth set to -1. That setting stops long strings from being wrapped across lines: a 30-word string stayed on one line in our test. A tab indent choice falls back to 2 spaces, since YAML forbids tab indentation. The tool refuses to minify YAML, with the message that YAML can't be minified safely because indentation is part of its syntax. Everything runs in your browser, so nothing is uploaded. The losses above apply here too: comments are removed and anchors are renamed, so use it on a copy.

Keep the original, format a copy, and diff the two before replacing anything. A diff shows what the round trip changed in seconds. Before you convert, scan for four things: comments you want to keep, anchors or <<, integers over 15 digits, and bare values like no, 010, or 1e3 that another parser might read differently. Quote the strings that must stay strings. If the YAML is only a stepping stone to another format, see the related guides on converting JSON to CSV or YAML. For a one-off check of whether a file parses, paste it into the Code Beautifier at /code-beautifier and read the error message if it fails.