Developer tools · Syntax converters
YAML to JSON type coercion: how yes, no and 0777 change meaning
· How it works
yaml json data-formats
YAML resolves unquoted scalars into types, and the rules differ between YAML 1.1 and 1.2. This post shows exactly how a converter decides that a value is a boolean, an integer, a float or a string, and how to control the outcome.
The value that came back as true — a plain YAML scalar meant as text, converted to JSON as a boolean, and the service that then misbehaved
A value such as `NO` can become false in a YAML 1.1 loader, but that is not what this converter ships. Both ToolAcre choices use YAML 1.2 schemas, so `NO`, `yes`, `no`, `on` and `off` remain strings. The corrected opening matters because an example claiming that this panel turns `NO` into true or false would teach the opposite of its tested behaviour.
Type surprises still exist. Under the default JSON schema, `null` is null while `~`, an empty value and `0o755` remain strings. Selecting Core changes those three forms to null, null and 493. The output is useful precisely because it exposes the resolved JavaScript value, rather than pretending that every plain YAML token carries an obvious type.
The value that stayed text under YAML 1.2
Implicit resolution occurs while js-yaml reads the source. The selected restricted schema decides whether a plain scalar matches a null, Boolean or numeric form before the converter writes JSON. Quoting bypasses that decision: `"0o755"` is text under either schema, and a block scalar remains a string including the line breaks represented by its chomping indicator.
This is parsing and serialization, not a regular-expression replacement. The reader builds strings, numbers, booleans, nulls, arrays and objects; `JSON.stringify` then emits those values with the selected indentation. Comments and token spelling are already gone by the writing stage, so no serializer can reconstruct whether a number was originally decimal or written in another accepted YAML notation.
The YAML 1.1 rules — yes/no/on/off booleans, 0777 as octal, 1:30 as sexagesimal, and version strings like 1.10 read as floats
The outline lists YAML 1.1 coercions such as sexagesimal time and legacy octal. They are relevant compatibility hazards, but they are not modes available here. ToolAcre intentionally does not offer a 1.1 schema. Its UI says that neither shipped option reads `NO` as false, and tests pin that country code and the words yes, no, on and off as strings.
That boundary changes the debugging method. If another application turns those words into booleans, compare its parser configuration with ToolAcre instead of expecting identical output. The converter can show what its own two schemas produce; it cannot certify the schema or version used by a CI runner, framework or deployment system that later consumes the file.
YAML 1.1 coercions are hazards this converter avoids
The default JSON schema accepts only scalar spellings compatible with JSON’s model. Core adds the familiar YAML null forms, hexadecimal and octal integers, Infinity and NaN. Core still stays inside a restricted loader: language-specific object tags, dates, sets, ordered maps and binary tags are refused rather than constructed.
Infinity and NaN reveal another boundary. JavaScript can hold them, but JSON cannot write them. The converter identifies each path and warns that the value becomes null. That is an admitted lossy step, not a lossless conversion. A quoted `.inf` avoids it because the value then remains the literal string `.inf`.
The two shipped YAML 1.2 schemas differ only on documented scalar forms
Paste `tilde: ~`, `empty:`, `octal: 0o755`, `country: NO` and `answer: yes`. With strict selected, the JSON values are `"~"`, `""`, `"0o755"`, `"NO"` and `"yes"`. With Core selected, only the first three change: tilde and empty become null, and octal becomes 493. Country and answer stay text in both outputs.
Now quote every value and repeat. Both schemas return strings because the source states the intended type. This comparison is code-accurate and more useful than contrasting YAML 1.1 with 1.2 inside a tool that never loads 1.1. It also gives a reviewable fixture for checking another parser without guessing from its documentation alone.
Worked example: one file under ToolAcre’s strict and Core schemas
Explicit standard tags are accepted only when the restricted schema recognises them: `!!str 123` becomes the string `123`, while `!!int "7"` becomes the number 7. Tags such as `!!binary`, `!!timestamp`, `!!set`, `!!js/function` and Python object constructors are rejected. This prevents the YAML reader from becoming an arbitrary-object factory.
Quoting remains the portable choice when a configuration value merely looks typed. It preserves leading zeroes, version spelling and sentinel words without depending on an explicit tag surviving another tool. The JSON result shows the chosen type, but it cannot carry the quote style or tag that produced that value.
What this does not cover — application-level parsing of the resulting JSON, which may coerce types again (for example, string '1' to number)
Application code may coerce the resulting JSON again. An API can read `"1"` and convert it to a number, or reject it against a schema. Syntax converters stops after producing JSON text; it does not run a framework validator, environment-variable loader or business rule. A clean conversion therefore proves syntax and mapping, not acceptance by the final service.
Duplicate YAML keys are a separate issue. ToolAcre keeps the last value and reports the repeated key with a position. Multi-document streams become arrays. Those choices can alter what an application sees even when every scalar type is expected, so read warnings rather than judging only the formatted JSON body.
Takeaway: quote anything a machine might misread — and how converting YAML to JSON in the browser reveals exactly what each scalar resolved to
Quote text that resembles a machine token, then inspect the JSON types. Use strict when you want the smallest JSON-shaped scalar vocabulary; choose Core deliberately when YAML null and numeric forms are required. Neither option is YAML 1.1, and neither makes a downstream consumer follow the same rules.
The panel makes its parser choice visible and returns warnings for values no target can represent. That is the honest promise: it reveals how this implementation resolved each scalar. It does not claim universal YAML behaviour or preserve comments, tags and spelling through a round trip.