JSON to YAML Converter

What is the actual difficulty in converting JSON to YAML?

Not the structure. Objects become mappings, arrays become sequences, and nesting becomes indentation. That part is mechanical.

The difficulty is quoting. YAML tries to be readable, which means it guesses the type of an unquoted value. JSON never guesses, because a string is always in quotes. So the conversion has to decide, for every string, whether YAML would still read it as a string once the quotes are gone.

Get that wrong and the data changes type silently:

JSON:  { "enabled": "yes", "version": "1.0" }

Naive YAML:     enabled: yes        ← now a boolean
                version: 1.0        ← now a number, trailing zero gone

Correct YAML:   enabled: 'yes'
                version: '1.0'

This page uses the js-yaml serialiser, which applies the full quoting rules rather than a shortlist of special cases. The stats row tells you how many values needed quoting, which is usually more than people expect.

Values that must be quoted, and why

The Norway problem

The most famous instance of this. A list of ISO country codes:

countries: [GB, NO, DE, FR]

reads as ["GB", false, "DE", "FR"], because NO is a YAML 1.1 boolean. The same applies to ON for Ontario and Y in a single-letter code list. Converting from JSON here quotes them, so the problem cannot occur in the generated output.

How to convert

1. Paste JSON An invalid document is reported with the line and column rather than a generic failure.
2. Pick the indentation Two spaces is the near-universal convention. YAML forbids tabs entirely, so this is always spaces.
3. Choose the quote character Single quotes need no backslash escapes, so they read more cleanly. Double quotes support \n and \t escapes.
4. Optionally sort keys or force quotes Sorting makes two configs diffable. Forcing quotes everywhere is verbose but leaves nothing to interpretation.

Examples: multi-line strings become block scalars

A JSON string containing newlines has only one representation — escaped \n. YAML has three, and the readable one is a block scalar:

JSON:
{ "description": "First line.\nSecond line.\nThird line." }

YAML:
description: |-
  First line.
  Second line.
  Third line.

The indicators are worth knowing because they change what the value actually is:

The serialiser picks the indicator that reproduces your JSON string exactly, which is usually |- because a JSON string rarely ends with a newline.

What conversion cannot add

Some YAML features have no JSON source, so they cannot appear in converted output. This is not a tool limitation — the information does not exist in the input.

• Comments. JSON has no comment syntax, so there is nothing to carry across. If you are regenerating a config from JSON, any comments in the original YAML are gone.
• Anchors and aliases. &defaults and *defaults express shared structure. JSON duplicates the data instead, so the shared relationship is not recoverable from the JSON alone.
• Merge keys. <<: *defaults depends on anchors, so the same applies.
• Multiple documents. A YAML stream can hold several documents separated by ---. One JSON document produces one YAML document, though you can add the --- marker if you intend to concatenate several.
• Explicit tags. !!set, !!binary and custom tags describe types JSON has no way to signal.

Going the other way makes the loss concrete: the YAML to JSON converter lists exactly which of these features it had to discard from your input.

Use cases

• Writing a Kubernetes manifest. Cluster APIs return JSON; manifests are conventionally YAML. Converting gives you a starting file, though you will want to add comments back.
• Producing a GitHub Actions workflow. Generate the structure programmatically as JSON, then convert to the YAML the runner expects.
• Making a config readable for review. YAML is typically 20–30% shorter than the equivalent JSON and easier to scan in a pull request.
• Building a Docker Compose file. Convert a JSON service definition into the compose.yaml layout.
• Creating an OpenAPI document. Both formats are valid; YAML is easier to hand-edit afterwards.
• Seeding an Ansible or Helm values file. Convert existing JSON defaults into the YAML those tools read.

Related config conversions: TOML to JSON, Properties to YAML, and the YAML Formatter for tidying an existing file.

Privacy

Parsing and serialising both run in your browser. The JSON is not uploaded, which matters when a config contains internal hostnames or secret references. Usage analytics record only the indentation setting and a coarse size band.