YAML vs JSON Examples: Check Values, Types and Nesting

Start with the data you intend to represent

A useful YAML versus JSON example shows the same values in two syntaxes. It should make types and nesting visible, rather than suggesting that deleting braces from JSON is a reliable conversion method. In this example, a fictional job has a string code, a boolean flag, an integer retry count and a list of two steps.

The code deliberately starts with zeros and the first step contains a colon in its display label. Those values expose mistakes that a simpler name-and-age example can miss. The snippets contain synthetic data, so they can be pasted into a local converter without revealing a real configuration.

Read the corresponding object and list

{
  "job": {
    "code": "0072",
    "enabled": false,
    "retries": 0,
    "steps": [
      {"name": "stage: one", "done": true},
      {"name": "stage two", "done": false}
    ]
  }
}

job:
  code: "0072"
  enabled: false
  retries: 0
  steps:
    - name: "stage: one"
      done: true
    - name: stage two
      done: false

In both forms, steps contains two objects in a defined order. The done field belongs to the same step as the name beside it. In YAML, changing that indentation can change the structure or make the document invalid. In JSON, braces and commas delimit the corresponding structure.

The expected job.code is the string "0072", job.enabled is boolean false, and job.retries is numeric zero. The first step's name is the literal string "stage: one". If a conversion changes any of those types or values, it has not preserved the example.

Keep missing, empty and null separate

Consider the JSON object {"note":null,"label":"","tags":[]}. It explicitly contains a null, an empty string and an empty array. None of those is the same as omitting the corresponding property. Applications may use missing fields to request defaults while interpreting null as an instruction to clear a value.

In YAML, write the intended forms explicitly when demonstrating the distinction: note: null, label: "" and tags: []. Do not leave a value blank because you assume it means an empty string. The parser's schema determines how plain scalars are resolved, so your test must inspect the parsed value.

The YAML 1.2.2 specification describes these scalar-resolution rules. Keep the parser version and schema visible in a project that exchanges YAML across tools. A claim that a particular spelling always means the same type in every YAML implementation is too broad.

Quote values when ambiguity would be expensive

String identifiers, version labels and user-facing text deserve explicit treatment. A value that looks numeric may still be an account code, and a date-shaped label may be intended as plain text. Quoting those values communicates the intended type to readers and prevents an avoidable conversion surprise.

A JSON string uses double quotes and escapes embedded double quotes or control characters according to the JSON grammar. YAML has several string styles. Choose a simple quoted style for this exercise; multiline block styles introduce additional newline behavior that should be tested separately.

Comments are another visible difference. A YAML comment can explain why retries is zero, but ordinary JSON has no comment syntax. Preserve the explanation outside the converted data if it matters to maintainers. Converting to JSON and back generally does not reconstruct the original comment placement.

Check the round trip and one malformed input

In the local JSON to YAML tool, select JSON to YAML and paste the first snippet. Inspect the resulting values, then choose YAML to JSON and paste the second snippet. Compare the parsed objects rather than requiring identical whitespace or quote style.

Next change the second step's done value to true. The converted object must show that single change. Remove a closing brace from the JSON input and confirm the tool reports an error and clears the old result. A converter must distinguish an unsuccessful attempt from a previous successful conversion.

When moving beyond this restricted example, test the actual values your application accepts. Large numbers, custom YAML tags, aliases and specialized date types need an explicit conversion policy. Keep the original document until the destination application's parser and configuration checks confirm the converted file behaves as intended.

This browser converter accepts a bounded JSON-compatible subset and rejects unsupported values explicitly. For example, YAML infinity cannot become a JSON number, and a parser-created date object cannot be silently presented as unchanged text. Ordinary acyclic aliases may be expanded within the tool's limits, but comments and original quoting style are not retained by that data conversion.

Related guides

OpenAPI JSON vs YAML: Preserve the Same API Description

Convert an OpenAPI description between JSON and YAML while preserving response keys, references and schema meaning, then validate its version.

JWT Decode vs Verify: Reading Claims Does Not Establish Trust

Distinguish JWT decoding, signature verification, claim validation, and authorization, with a tampering example and clear local-tool limits.

JSON Rich Snippets: Diagnose Markup and Search Eligibility

Separate JSON syntax, structured-data vocabulary, search-feature support, and crawling when investigating a missing rich result.