YAML values that look like strings—but are not

YAML is convenient for human-edited configuration, but a value’s appearance can be misleading. Before converting a configuration file, identify the schema and decide which fields are identifiers. SyntaxPad uses the YAML 1.2 core schema with a deliberately limited JSON-compatible subset.

Try this configuration

enabled: true
legacy_word: yes
postal_code: "00123"
empty_value: null
empty_text: ""
replicas: 3

Open JSON ↔ YAML, choose YAML to JSON and paste the sample. The expected types are boolean for enabled, string for legacy_word and postal_code, null for empty_value, string for empty_text, and number for replicas.

{
  "enabled": true,
  "legacy_word": "yes",
  "postal_code": "00123",
  "empty_value": null,
  "empty_text": "",
  "replicas": 3
}

Under this schema, yes is a string. Some other YAML implementations or older schemas treat it differently. Check the receiving application rather than assuming all YAML parsers agree. Quoting identifiers is a useful way to communicate intent, especially when leading zeros matter.

Null and empty text are different

A null value usually expresses the absence of a value. An empty string is still a string with zero characters. Your application may handle them differently. Compare the two fields in the output and preserve whichever meaning your configuration requires. The converter does not turn both into the same empty string.

Unsupported structures fail clearly

JSON object keys must be strings. YAML keys such as an unquoted boolean or a sequence are rejected here. Explicit tags, aliases and multiple YAML documents are also outside the tool’s scope. Expand aliases into ordinary values and convert one document at a time. Infinity and NaN have no JSON number representation and cannot be converted as numbers.

Duplicate keys are rejected, as are integers outside the safe range. Quote a long identifier if it must remain exact. If a file relies on custom tags, merge behavior or application-specific types, use that application’s parser instead of rewriting it through this converter.

The return trip is about data

Convert the JSON result back to YAML and compare values and types. The original comments, quote style, blank lines and key formatting will not survive. Keep the original configuration under version control when editorial comments matter. Review the converted file before using it in a service; this tool checks representability, not whether the service accepts those settings.

References: YAML 1.2.2 specification; YAML parser documentation.

Try the same steps

Open JSON ↔ YAML and load the example to get started.