Why a JSON→YAML Converter Auto-Quotes Certain Strings
You may have noticed that converting JSON to YAML sometimes wraps a particular string in quotes that weren't there in the original — quotes it seemingly added out of nowhere. It looks like a bug, but it's actually the opposite: the converter is deliberately doing this to preserve the original string's intent. This guide looks at why YAML needs this kind of safeguard in the first place, and how a real converter implements the rule in code.
1. YAML's double-edged convenience: unquoted strings
Unlike JSON, YAML doesn't require quotes around strings. A value like name: Alice with no quotes at all (a plain scalar) is still parsed as a string. That flexibility is exactly what makes YAML pleasant to read as a config format — but it's also a trap. When a YAML parser encounters an unquoted value, it has to decide for itself, purely from how the value looks, whether it's a string or something else entirely — boolean, null, number.
2. When a string that looks like a reserved word actually changes type
Under the YAML 1.1 spec, not just true and false but also yes, no, on, off, null, and ~ are all parsed as booleans or null, case-insensitively. If the original data was a user's text response of the literal string "yes," and it gets written out to YAML unquoted, a parser reading that YAML back in will interpret it not as the string "yes" but as the boolean true. A value that was unambiguously a string in the original JSON silently changes type on its way through YAML. This is the same family of trap as the well-known "YAML Norway problem," where the country code NO gets misread as the boolean false.
3. The converter's defense: automatic quoting
The fix is simple. If a string value looks exactly like a reserved word, starts with a digit, or contains a colon or other special character that would collide with YAML syntax, the converter can automatically wrap it in quotes to explicitly mark it as "this is a string." A safe converter shouldn't leave that judgment call to the user — it should handle it automatically at conversion time, so that when the resulting YAML is parsed back, the value and type match the original JSON 100% of the time (round-trip safety).
4. Does MODOO HUB's JSON to YAML converter actually behave this way?
The JSON to YAML converter uses the js-yaml library's dump() function under the hood. js-yaml's default behavior already auto-quotes any string that could be mistaken for true/false/null or a number, and this tool uses that library default as-is, with no custom logic layered on top. In other words, the safe behavior is baked into the default — you don't need to flip on any option for it.
{"status":"yes","code":"no","flag":"true","value":"null"} into the JSON to YAML converter. If all four values in the resulting YAML come out wrapped in quotes, that confirms the tool is correctly defending against reserved-word-like strings.
5. In practice: which strings get quoted
| Original JSON value | Output unquoted | Actual output (auto-quoted) | Reason |
|---|---|---|---|
| "yes" | yes (risk of being read as boolean true) | 'yes' | Matches a YAML 1.1 reserved word |
| "no" | no (risk of being read as boolean false) | 'no' | Matches a YAML 1.1 reserved word |
| "123" | 123 (risk of being read as a number) | '123' | Looks like a number |
| "hello" | hello | hello (no quotes needed) | Plain string unrelated to reserved words or numbers |
As the last row shows, an ordinary string that has nothing to do with reserved words or numbers is left unquoted. So the rule isn't "quote every string unconditionally" — the key point is that only strings at risk of misreading get selectively wrapped. The same rule matters in the opposite direction too: when you use a YAML-to-JSON tool to convert back, the original types can only be restored accurately if the YAML followed this rule in the first place.
Frequently Asked Questions
Q. Does every string get wrapped in quotes?
A. No. Only strings at risk of misreading — ones identical to a reserved word like true/false/null/yes/no, or starting with a digit — get auto-quoted. Ordinary strings are output unquoted as-is.
Q. How exactly does this relate to the YAML Norway problem?
A. The Norway problem is the famous case where the country code "NO" gets misread as the boolean false under the YAML 1.1 spec. The auto-quoting this guide covers is exactly the safeguard that prevents cases like this at conversion time.
Q. Is this problem fixed in YAML 2.0?
A. YAML 1.2 narrowed the set of literals read as booleans down to just true/false, reducing the yes/no/on/off issue. But many widely used parsers in practice (like PyYAML's default) still follow YAML 1.1 rules, so automatic quoting remains a safe practice.
Q. What happens to a value that starts with a digit but is actually a string (like a postal code)?
A. A digit-only string like "01234" risks being read as an integer if left as-is, so it gets auto-quoted too. Preventing an accident like a leading zero silently disappearing is also part of what this safeguard does.