Loading YAML to JSON Converter…
Paste YAML above to convert it.
The YAML side is a parser for the subset configuration files use: maps, sequences, nested indentation, quoted and plain scalars, comments and multi-document streams separated by ---. Anchors (&name), aliases (*name), merge keys, explicit tags and block scalars (| and >) are refused by name and line rather than mis-read, so a file using them never converts into something subtly wrong.
YAML and JSON describe the same three things: mappings of keys to values, ordered sequences, and scalars. That is why conversion between them is possible at all, and why it is a re-serialisation rather than a text substitution — the document is read into values and written out again in the other notation. Conversion runs in either direction here, so a Docker Compose file becomes JSON an HTTP client will accept, and a JSON response becomes the YAML shape a Helm values file expects.
Where a YAML stream holds several documents separated by ---, JSON has no equivalent, so the result is an array with one entry per document and a count on screen saying so. The alternative, taken by a surprising number of converters, is to convert the first document and drop the rest in silence.
Almost every YAML failure is an indentation failure, and the useful part of the answer is which line. A list whose second item is indented deeper than its first answers “Line 3: Indentation is off: this line starts at column 5, but the block it is in starts at column 3”. A key indented under a scalar rather than a mapping is caught where it appears, not two lines later where the shape finally becomes impossible.
Four more faults get named rather than described vaguely. A tab used for indentation is rejected outright, because YAML forbids tabs there and an editor set to hard tabs is the usual cause. A line with no colon-space pair is reported as such, and an opening quote with no partner is caught on its own line rather than swallowing the rest of the file. A key repeated inside one mapping is an error too, not a silent overwrite, because the duplicate you can see is the one that would have been discarded.
The parser covers what configuration files actually contain: nested mappings, block sequences whose dashes sit either under or level with their key, compact entries such as - name: web with more keys below, plain and quoted scalars with their escapes, comments anywhere, and inline flow collections like [80, 443] or {app: api}.
Five constructs are refused by name and line instead of being guessed at: anchors (&defaults), aliases (*defaults), merge keys (<<), explicit tags (!!str), and block scalars (| and >). Each of them changes the meaning of the document in ways a subset parser cannot reproduce, and a converter that ignored an anchor would hand back JSON that looked complete and was missing values. If your file uses one, expand it by hand before converting.
YAML infers types from the way a scalar is written, so conversion can change what a value is. version: 1.0 is a number and arrives in JSON as 1, the trailing zero gone, while version: "1.0" stays the string you probably meant. An unquoted country code NO stays the string "NO" here, following the YAML 1.2 core schema — the 1.1 rules read it as false, which is the famous bug that deleted Norway from a list of countries.
Integers longer than a JavaScript number can hold exactly are kept as strings rather than rounded, so a 19-digit identifier survives the trip, and both an empty value and ~ become null. On the way back out, any string that would be re-read as something else — "true", "1.0", "NO", or an empty one — is quoted, so a second pass returns the same document rather than drifting further each time.
Almost always because one line uses a tab where the others use spaces, or because a nested block sits at a column that no enclosing block opened. The line number in the message is the first line that could not belong to the block above it, which is usually the line after the mistake.
Yes. Each --- section is parsed separately and the JSON output is an array in file order, with the document count shown beside it. Anchors are the one thing to watch for, since large manifests sometimes share a block of defaults that way, and those are refused rather than expanded.
They are read, then discarded, because JSON has no syntax for them. That makes this a lossy direction for anything hand-maintained: convert a commented config and the explanations are gone. Keep the YAML file as the source of truth and treat the JSON as output.
Only where leaving them off would change the type on the next read. Writing JSON back to YAML quotes strings such as "true", "off", "1.0" and "" so they stay strings, and leaves ordinary words bare. It is the minimum quoting that survives a round trip.