Converting YAML to JSON Without Corrupting Your Data
By the Super Simple Digital Tools Team · Updated June 2026
YAML and JSON describe the same shapes of data, nested objects and ordered lists, but they make opposite trade-offs. YAML optimizes for humans: indentation instead of braces, optional quotes, comments, and reusable anchors. JSON optimizes for machines: explicit delimiters, no ambiguity, and a parser built into virtually every language. Converting from one to the other is rarely about preference. It is about meeting a tool where it lives. Your CI pipeline reads YAML, but the API you call wants JSON, so a translation step sits between them.
Mechanically, a converter parses your YAML into a tree of three things: mappings (key-value pairs), sequences (lists), and scalars (single values). Indentation defines the nesting, a dash defines a list item, and a colon separates a key from its value. Once that tree exists in memory, emitting JSON is straightforward: wrap mappings in braces, wrap sequences in brackets, quote every key, and choose a JSON type for each scalar. The interesting and occasionally dangerous part is that last step, because YAML decides scalar types for you when you do not quote them.
This is where conversions go wrong. Write port: 8080 and you get a number, which is usually what you want. Write version: 1.10 expecting a string and many parsers hand you the float 1.1, dropping the trailing zero. Write country: NO and a YAML 1.1 parser gives you the boolean false. Write zip: 08080 and some parsers treat the leading zero as octal. None of these raise an error. The YAML is valid, the JSON is valid, and the value is simply wrong. Converting to JSON is actually a useful way to catch these, because JSON shows the resolved type plainly.
Indentation is the other classic failure. The YAML spec only allows spaces for indentation, never tabs, and roughly the majority of YAML syntax errors trace back to indentation problems. A single tab character, or two keys at the same logical level that are indented by different amounts, will stop the parse. Configure your editor to show whitespace and to insert spaces when you press Tab. Pick two spaces per level and keep every key in a block aligned. Consistent, space-only indentation prevents most of the errors you will ever hit.
A clean workflow looks like this: quote any value that should stay a string, especially codes, versions, and anything with leading zeros; remove or accept the loss of comments since JSON cannot keep them; expect anchors to be expanded into full copies; and review the JSON output to confirm numbers, booleans, and nulls landed where you intended. Because this tool runs the whole conversion in your browser, you can paste sensitive config without it leaving your machine, then copy the JSON straight into your request body or config loader.
- Never indent YAML with tabs. Set your editor to insert two spaces per level and to render whitespace so stray tabs are visible.
- Quote any value that must stay a string: country codes like NO, versions like 1.10, and ZIP or ID numbers with leading zeros such as 08080.
- Remember comments and anchors will not survive. Comments are dropped and anchors are expanded into full duplicated values in the JSON.
- Use the JSON output as a type check: if a field shows up as a number, boolean, or null when you wanted a string, fix the quoting in your YAML and convert again.