Unlike JSON-to-XML, this direction has no convention to invent: a YAML mapping is a JSON object, a YAML sequence is a JSON array, and YAML's scalars are the same strings, numbers, booleans and null JSON already has. Converting is really just re-serializing the same values — which is also why it's the one conversion on this site with no "known limitations" about lost information.
The example below is a Kubernetes Deployment fragment — the kind of document YAML is used for constantly and JSON almost never is, which is usually the actual reason someone wants this conversion: editing structured data by hand in the format their tooling expects.
Before and after
This is loaded in the converter above.
{
"apiVersion": "apps/v1",
"kind": "Deployment",
"metadata": {
"name": "checkout",
"labels": {
"app": "checkout"
}
},
"spec": {
"replicas": 3,
"selector": {
"matchLabels": {
"app": "checkout"
}
}
}
}apiVersion: apps/v1
kind: Deployment
metadata:
name: checkout
labels:
app: checkout
spec:
replicas: 3
selector:
matchLabels:
app: checkout
How the mapping works
Nesting becomes indentation
A JSON object's keys become YAML's block-mapping syntax (key: value, indented under their parent), and a JSON array becomes a block sequence (- item, one per line). There's no attribute/text distinction to design around, because neither format has attributes.
Strings are quoted only when YAML would otherwise misread them
apiVersion: apps/v1 is written bare — an unquoted plain scalar — because YAML has no trouble parsing it as a string. A value that looks like a YAML number, boolean, or null (like the text "true", "null", or "123") is quoted so it round-trips back as a string rather than being reinterpreted as that other type. A string containing ": " (colon-space) is quoted for the same reason: unquoted, YAML would read it as another key-value pair rather than one value.
A multi-line string becomes a block literal, not an escaped one-liner
A JSON string containing \n is written using YAML's | block-literal style — the text on its own indented lines — rather than as one quoted line with a literal backslash-n in it. It reads the way the original text actually looks, which matters for anything like a multi-line description or a shell command embedded in a CI config.
Known limitations
- None specific to this direction: every JSON value (object, array, string, number, boolean, null) has a direct YAML equivalent, so nothing here is a guess the way an attribute or a repeated tag name is on the XML side. The one thing to know is general to YAML, not to this converter: a YAML document can express things JSON can't (anchors and aliases for repeated structures, multiple documents in one file, comments) — converting JSON to YAML will never produce those, since JSON has nothing for them to come from.
JSON to YAML FAQ
Is this conversion ever lossy?
Not for anything JSON itself can represent. Every object, array, string, number, boolean and null maps directly to its YAML equivalent with nothing left to guess.
Why are some strings quoted and others not?
A string is quoted only when leaving it bare would change its meaning in YAML — for example the literal text "true" or "123", which would otherwise parse back as a boolean or a number instead of a string.
Can I convert a Kubernetes manifest or docker-compose file this way?
Yes for the direction of pasting JSON and getting YAML out — most infrastructure tooling accepts both, and this produces valid YAML for anything that started as valid JSON.
Is my data uploaded anywhere?
No. Conversion runs in your browser, which matters here since Kubernetes and CI configs often contain internal service names.
Other conversions
Every direction between JSON, XML and YAML — including YAML as a starting point — is available directly from the From/To selectors in the converter above, whichever page you're on.