YAML ↔ JSON Converter

What it does

Paste YAML and get JSON, or paste JSON and get YAML. Pick a 2- or 4-space indent for the output, hit Swap panes to feed a result back through in the other direction, and copy the result out. Parse errors come back with the line and column the parser choked on plus a snippet of the offending line, so a bad indent is obvious instead of mysterious.

Multi-document YAML works too. A file with --- separators, the shape you get from kubectl get all -o yaml or from a concatenated manifest, parses every document and emits a JSON array with one element per document in file order.

How it works

YAML parsing runs through js-yaml against the YAML 1.2 core schema, loaded in your browser. JSON parsing and serialising use the engine’s native JSON.parse and JSON.stringify, which implement RFC 8259. No request goes to a server. Your input is mirrored into the query string up to 2 KB so you can bookmark or share a conversion; larger inputs stay in the textarea only.

Because JSON is a strict subset of YAML in the 1.2 spec, JSON to YAML is mechanically easy and nearly always lossless. The interesting direction is YAML to JSON, where several YAML features have no JSON equivalent and have to be flattened.

What gets lost in the round trip

Three things disappear, and it is worth knowing which before you rely on the output.

Comments go first. JSON has no comment syntax, so every # line is dropped. This tool converts data, not documents. If your YAML carries the only written explanation of why a timeout is 45 seconds, do not round-trip the file through JSON and commit the result; edit the YAML in place instead.

Anchors and aliases are resolved rather than preserved. &defaults with *defaults, and the << merge key, get expanded, so the JSON you get back is the fully materialised document with values duplicated wherever a merge pulled them in. That is exactly what a consumer such as the Kubernetes API server sees after parsing, which makes it a good way to check that a merge did what you thought. It is also lossy if you wanted the shorthand to survive.

Finally, mapping keys are converted to strings, and tags outside the core schema will not resolve.

The other trap is type coercion. YAML 1.1 treated yes, no, on, and off as booleans; the YAML 1.2.2 specification narrowed the core schema so those are plain strings. That is why enable_tls: no reads as the string "no" here while an older Ruby or Python parser might hand you false. The same class of bug bites unquoted version numbers: version: 1.10 is the number 1.1, and version: "1.10" is the string you meant. Quote deliberately whenever a scalar’s type matters, and remember that Kubernetes resource fields are validated against their declared types in the API object model, so a string where an integer belongs is rejected at apply time rather than silently coerced.

When to reach for it

• A tool wants JSON and your config is YAML, or the reverse, and you would rather not write a five-line script for it.
• You are staring at a nest of anchors and merge keys and want to see the flattened result before applying it.
• An API returned JSON and you want a human-editable version to hand to somebody who will edit it by hand.
• You suspect a type coercion bug and want a second parser’s opinion on what a scalar actually is.

Related tools

• JSON formatter and validator once the JSON side needs pretty-printing or minifying.
• Kubernetes YAML linter for manifest-specific checks a generic parser will not make.
• Base64 encoder/decoder when the config arrives wrapped in a Secret or ConfigMap value.

Also useful nearby: the JWT decoder for the Base64url blobs in service-account tokens, and the URL encoder/decoder when a config value has to survive a query string.