JSON to YAML

The YAML appears here.

{
  "apiVersion": "apps/v1",
  "kind": "Deployment",
  "metadata": {
    "name": "cave-api",
    "labels": {
      "app": "cave-api",
      "version": "1.10"
    }
  },
  "spec": {
    "replicas": 3,
    "selector": {
      "matchLabels": { "app": "cave-api" }
    },
    "template": {
      "metadata": {
        "labels": { "app": "cave-api" }
      },
      "spec": {
        "containers": [
          {
            "name": "api",
            "image": "registry.example.com/cave-api:2026.09.12",
            "ports": [{ "containerPort": 8080 }],
            "env": [
              { "name": "REGION", "value": "no" },
              { "name": "LOG_LEVEL", "value": "debug" }
            ]
          }
        ]
      }
    }
  }
}

---
apiVersion: apps/v1
kind: Deployment
metadata:
  name: cave-api
  labels:
    app: cave-api
    version: '1.10'
spec:
  replicas: 3
  selector:
    matchLabels:
      app: cave-api
  template:
    metadata:
      labels:
        app: cave-api
    spec:
      containers:
        - name: api
          image: registry.example.com/cave-api:2026.09.12
          ports:
            - containerPort: 8080
          env:
            - name: REGION
              value: 'no'
            - name: LOG_LEVEL
              value: debug

What YAML changes about your data

Nothing — and everything, depending which question you mean. The values in a JSON document and the values in its YAML equivalent are the same values: the same string, the same number, the same array in the same order. What changes is how a YAML reader decides what a bare word means, and that decision is where every head-of-search converter gets measurably wrong answers. A YAML parser looks at unquoted text and has to guess whether no is a string or the boolean false, whether 0777 is decimal 777 or octal 511, whether 12:30 is a string or the sexagesimal number 750. JSON never asks this question — a string is always quoted — so converting to YAML is the first time your data is exposed to a reader's guesswork at all. This tool's whole job is making sure that guess always lands on the value you actually had.

Why "no" and "1.10" get quoted

YAML 1.1 — the spec SnakeYAML, PyYAML and go-yaml v2 implement, which means Spring Boot, Ansible and Kubernetes tooling — resolves a bare no, off, n or NO to the boolean false. A country code, a feature flag, or a two-letter region written bare stops being the text you wrote the moment a 1.1 reader opens the file. Likewise 1.10 written bare is the number 1.1 to every YAML reader regardless of spec — the trailing zero, which is exactly the digit that distinguishes a version label from a smaller number, is silently gone. This tool's quoting predicate checks the union of six real reader profiles rather than one spec, so a value is quoted the moment any of them would misread it — never only the one you happened to pick.

Six real YAML readers and what they do with three traps

Reader	Spec	Used by	no	y	1e3
YAML 1.2 core	1.2	js-yaml 4, yaml 2, ruamel, yq (Go)	text	text	number
PyYAML	1.1	PyYAML, Ansible, Home Assistant	false	text	text (needs a signed exponent)
SnakeYAML	1.1	SnakeYAML, Spring Boot, Jenkins	false	text	text
go-yaml v2	1.1	Kubernetes tooling, Helm, kubectl	false	boolean true	text
go-yaml v3	1.2-ish	Compose v2, many Go CLIs	text	text	number
Psych	1.1	Ruby, Rails, GitLab CI	false	text	text

Sequence indentation styles, and who uses which

YAML allows a block sequence's dash either flush with its parent key or indented two spaces under it — both parse identically, but house styles disagree, which is why this tool exposes it as an option rather than picking silently. Kubernetes manifests and Compose files nearly always indent ( - a under the key); GitHub Actions workflows and Ansible playbooks are usually flush (- a at the same column as the key). The four preset chips above set this along with the other style options a switcher would otherwise hunt through a menu for.

Block scalars

A JSON string containing newlines becomes a YAML block scalar rather than an escaped one-liner, because |-style block text is what a human editing the file actually wants to read. The exact trailing-newline behaviour matters: | keeps exactly one trailing newline, |- strips it, and |+ keeps every trailing blank line — this tool picks whichever spelling reproduces your string's exact bytes, and the verification receipt is how it knows it chose correctly rather than approximately.

Why comments from JSONC survive

Files like tsconfig.json, .eslintrc.json and VS Code settings are JSONC — JSON with // and /* */ comments the strict spec does not allow. Most converters read these with a JSON.parse-compatible loader and drop every comment silently. This tool's JSON engine keeps a comment's exact text and position on a side list rather than discarding it, so a comment above a key can be attached to the same key in the YAML — turning a config file's original context into # lines rather than losing it on the way across.

The six readers and what each would do with the other tools' output

Measured directly (2026-09-12): the two most common libraries behind competing converters write no, 12:30 and 2024-01-15 unquoted by default — correct for a YAML 1.2 reader, wrong the moment the file reaches SnakeYAML, PyYAML or go-yaml v2. Nobody in that field prints which reader their output is actually safe for. This tool's reader matrix (the Readers tab above) answers that question directly, per conversion, for the six profiles it tracks — a checkmark per reader is a claim you can verify, not an assumption you have to trust.

The numbers no YAML reader keeps exactly

A 20-digit id like a Snowflake ID or a bigint database key survives this conversion as the exact digits it started as — this tool's JSON engine never routes a number through a 64-bit float. But the receipt is honest about what happens next: if you then open that YAML with js-yaml or PyYAML, their loader will round it to the nearest representable double, because that is what those libraries do internally regardless of what the file says. The receipt names this ("some JSON readers would round this") rather than implying the number is safe everywhere just because it left here correctly.

Doing this from the terminal

Three common ways to do the same conversion outside a browser, each with the caveat that matters:

• yq -o=yaml input.json — mikefarah's yq uses a 1.2-family YAML library, so it will not add the quoting a 1.1 reader like SnakeYAML or Ansible needs.
• python -c 'import yaml, json; print(yaml.safe_dump(json.load(open("input.json"))))' — json.load already rounds any integer past 2^53 written as a JSON number, and PyYAML's safe_dump will not quote a bare no for you; it writes whatever Python's own type already is.
• node -e "console.log(require('js-yaml').dump(JSON.parse(require('fs').readFileSync('input.json','utf8'))))" — JSON.parse has the same 2^53 problem, and js-yaml's dump quotes some traps (the single-letter booleans) but not others (a bare 1_000).

Common use cases

• Turning a kubectl get -o json dump into a manifest you can hand-edit and reapply
• Converting a Terraform or AWS CLI JSON export into readable YAML for a docs repo
• Checking which YAML readers would safely reproduce a JSON config before shipping it
• Turning NDJSON log output into multi-document YAML for inspection
• Carrying JSONC comments from a settings file into a hand-maintained YAML equivalent