UtilityKit

500+ fast, free tools. Most run in your browser only; Image & PDF tools upload files to the backend when you run them.

JSON ↔ YAML

Convert between JSON and YAML formats

About JSON ↔ YAML

JSON is what APIs speak; YAML is what humans and Kubernetes read. The JSON-YAML converter switches between formats without mis-quoting bare strings or triggering the Norway problem where NO becomes boolean false in YAML 1.1. DevOps engineers translating Kubernetes manifests and docker-compose files appreciate that the tool emits YAML 1.2, the dialect modern tooling expects. Backend developers porting OpenAPI specs can paste raw JSON and receive clean indented YAML in seconds. Multi-document YAML files separated by --- parse into a JSON array and reconstruct correctly on the way back. YAML anchors and aliases are resolved to plain JSON. Inline validation highlights bad indentation and stray tabs with line numbers so you catch errors before kubectl apply. Because js-yaml runs in your browser, Helm values and CI secrets never reach a remote server.

Why use JSON ↔ YAML

Round-Trip Without Quoting Drift

YAML bare strings, JSON mandatory quotes, and edge cases like "yes" or "no" booleans are normalised to the correct type for each format. Values that should stay strings — like the word on in a GitHub Actions trigger — are quoted in output to prevent silent type mismatches.

Spec-Compliant YAML 1.2 Output

Emits 2-space indented YAML 1.2, the dialect Kubernetes, GitHub Actions, and Ansible all expect. Avoids YAML 1.1 quirks like treating NO as false or mapping octal literals incorrectly, so your output works without manual fixup.

Multi-Document Support

YAML files separated by --- (common for combined Kubernetes Deployment and Service files) parse into a JSON array, and a JSON array converts back into multiple YAML documents. No manual splitting or merging required.

Inline Validation

Bad indentation, unclosed braces, or stray tab characters are flagged with line and column numbers before you copy a broken result into kubectl apply. Fix the source and the preview updates immediately.

Secrets-Safe Local Parsing

Helm values, Vault configuration snippets, and CI secrets never leave your browser tab. The js-yaml library parses and serialises entirely in JavaScript memory — no fetch request, no server, no logs.

Smart Anchor & Alias Handling

YAML anchors (&base) and aliases (*base) are resolved to their full values in JSON output so downstream tools see complete objects. The conversion is transparent and no references are left dangling.

How to use JSON ↔ YAML

  1. Pick a direction (JSON → YAML or YAML → JSON), or paste content and let the tool auto-detect the format
  2. Paste the source document into the left editor panel
  3. Watch live conversion appear in the right pane, with syntax errors highlighted by line number
  4. Toggle options such as pretty-printing, alphabetical key sorting, or flow vs block style as needed
  5. For Kubernetes multi-document files, verify that --- separators are handled and each document appears correctly
  6. Copy the result to clipboard or download as .yaml or .json

When to use JSON ↔ YAML

  • Translating a Kubernetes manifest from YAML to JSON when your tooling expects JSON input (e.g. Helm chart overrides)
  • Converting a GitHub Actions workflow or Ansible playbook snippet from JSON back to YAML after editing it programmatically
  • Porting an OpenAPI specification between YAML and JSON formats for different editors or validators
  • Validating a docker-compose or Helm values file for YAML syntax errors before deployment
  • Debugging a multi-document Kubernetes file (Deployment + Service) by inspecting the parsed JSON representation
  • Converting an API JSON response into YAML to add it as a fixture file in a YAML-based test suite

Examples

Kubernetes manifest YAML → JSON

Input: apiVersion: v1 kind: Service metadata: name: web spec: ports: - port: 80 targetPort: 8080 selector: app: web

Output: { "apiVersion": "v1", "kind": "Service", "metadata": { "name": "web" }, "spec": { "ports": [{ "port": 80, "targetPort": 8080 }], "selector": { "app": "web" } } }

API response JSON → YAML config

Input: {"database":{"host":"db.local","port":5432,"ssl":true},"cache":{"driver":"redis","ttl":3600}}

Output: database: host: db.local port: 5432 ssl: true cache: driver: redis ttl: 3600

Multi-document YAML

Input: --- kind: Deployment metadata: name: api --- kind: Service metadata: name: api

Output: [ { "kind": "Deployment", "metadata": { "name": "api" } }, { "kind": "Service", "metadata": { "name": "api" } } ]

Tips

  • Comments are a YAML-only concept — they are dropped when converting to JSON and cannot be reconstructed; keep originals in version control.
  • If you see 'on' or 'off' turning into booleans, the YAML parser is using 1.1 rules — quote them as "on" in the source to keep them strings.
  • Use 2-space indentation for YAML output (the Kubernetes convention); tabs are illegal in YAML and will fail kubectl apply immediately.
  • When converting JSON to YAML for git commits, sort keys alphabetically so diffs stay clean across teammates and CI validators.
  • For docker-compose files, prefer block style YAML over flow style — flow style works but makes code reviews much harder to scan.

Frequently Asked Questions

Is YAML really just JSON with cleaner syntax?
YAML is a superset of JSON — every valid JSON document is also valid YAML. However, YAML adds features like comments, anchors, aliases, multi-document streams, and bare unquoted strings, which have no equivalent in JSON. These extras are why YAML is preferred for human-edited config files.
Why does YAML choke on a value like NO or yes?
YAML 1.1 (used by many older parsers) treats bare NO, yes, on, off, true, and false as booleans. YAML 1.2 changed this so only true and false are boolean. This tool emits YAML 1.2, but if your target parser is older, quote values like 'NO' to force string interpretation.
How are JSON null values represented in YAML output?
JSON null becomes the bare YAML value null (or ~ in some serialisers). Both are equivalent in YAML 1.2. On the return trip, YAML null converts back to JSON null correctly.
Will my comments survive the YAML → JSON → YAML round trip?
No. Comments are a YAML-only concept and are discarded when converting to JSON because JSON has no comment syntax. They cannot be reconstructed on the way back. Keep the original YAML file in version control if comments matter.
Does it support Kubernetes-style multi-document YAML files?
Yes. A YAML file containing multiple documents separated by --- is parsed into a JSON array where each element corresponds to one document. Converting a JSON array back to YAML produces the multi-document form with --- separators.
What happens to YAML anchors and aliases when converting to JSON?
Anchors (&name) and aliases (*name) are resolved during parsing — each alias is replaced with a deep copy of the anchored value. The resulting JSON contains plain objects with no anchor references, which is correct for downstream tools.
Why is my converted YAML using flow style ({a: 1}) instead of block style?
Flow style is compact inline notation; block style uses indented newlines. The tool defaults to block style for readability, but small objects may be emitted inline based on depth heuristics. Toggle the block-style option to force all objects and arrays onto separate lines.
Can I trust this with secrets from a Helm values.yaml file?
Yes. The js-yaml library runs entirely in your browser — no data is sent to any server, and no request is made. Your API keys, database passwords, and Vault tokens stay in your browser tab memory and are cleared when you close the page.

Explore the category

Glossary

YAML 1.2
The current YAML specification that removes ambiguous implicit type rules from YAML 1.1, most notably restricting booleans to only true and false and fixing octal literal handling. Kubernetes and modern tooling use YAML 1.2.
Anchor (&)
A YAML feature that names a node with &anchorName so it can be reused elsewhere. Anchors allow DRY config by defining a block once and referencing it multiple times via aliases.
Alias (*)
A YAML reference to a previously defined anchor, written as *anchorName. The alias expands to a copy of the anchored value at parse time and is resolved to a plain value when converting to JSON.
Flow style vs block style
Two ways to write the same YAML data. Flow style uses inline JSON-like syntax ({key: val}); block style uses indented lines. Block style is preferred for readability in config files; flow style is compact for short values.
Multi-document stream
A single YAML file containing multiple independent documents separated by --- delimiters. Common in Kubernetes when bundling related resources (Deployment + Service) into one file.
Norway problem
A YAML 1.1 quirk where the bare country code NO is parsed as boolean false because it matches the yes/no boolean set. Fixed in YAML 1.2, but still a risk when working with older parsers or tools.