YAML to JSON converter (and back).

YAML is parsed with the open-source yaml library by Eemeli Aro, a zero-dependency parser that implements both YAML 1.2 and YAML 1.1 and reports exact positions. It runs inside your browser tab, so configs with hostnames, secrets placeholders or customer data never leave your machine.

Every document in the stream is read, anchors and aliases are resolved, and merge keys (<<) are applied. One document becomes one JSON value; several documents become a JSON array, one item per document. In the other direction, JSON is validated first (with the same line-and-column errors as our JSON formatter) and then written as block-style YAML.

Comments do not survive YAML to JSON, because JSON has no comment syntax. Key order is preserved both ways.

YAML 1.1 (2005) treats many plain words as booleans: yes, no, on, off, y and n in several capitalisations. So a list of country codes [GB, NO, IE] comes out as ["GB", false, "IE"], and Norway disappears. YAML 1.1 also reads 0755 as an octal number (493) and 22:30 as base-60 (1350). YAML 1.2 (2009, revised as 1.2.2 in 2021) keeps only true, false and null as special words, reads 22:30 as a string and treats a leading zero as plain decimal.

Which one you get depends on the library, not the file. PyYAML, and therefore many Python tools, follows 1.1. Ruby's Psych follows 1.1. go-yaml v3 reads 1.2 but still accepts yes/no/on/off when decoding into a bool field. js-yaml 4 and the yaml package follow 1.2. A classic case: PyYAML loads the top-level on: key of a GitHub Actions workflow as the boolean True.

The gotcha list under the output flags every plain value that the two versions read differently, plus values that quietly change in both: 3.10 becomes 3.1 and integers above 2^53 lose precision. The fix is always the same: quote the value. JSON to YAML in 1.1 mode quotes these strings for you, and the result reads the same under either version.

An anchor (&defaults) names a node, an alias (*defaults) reuses it, and a merge key (<<: *defaults) copies the anchored mapping's keys into the current one, with local keys winning. CI pipelines, Docker Compose files and Helm values use this to avoid repetition. Merge keys come from YAML 1.1 and are not part of the 1.2 core schema, but most tools support them and so does this converter.

JSON has no references, so each alias is expanded into a full copy. To stop a crafted file with nested aliases (a "billion laughs" attack) from freezing the tab, expansion is capped; real configuration never comes close to the cap.

A line containing only --- starts a new document, and ... can end one. Kubernetes manifests often bundle a Deployment, a Service and a ConfigMap in one file this way. The converter outputs a JSON array with one element per document, in order, and the status line tells you how many it found.

If you need one JSON file per resource, copy the elements individually. Note that kubectl accepts JSON manifests too, so the converted output can be applied directly. If you are new to the platform, our Kubernetes for small teams guide explains when it is worth it.

Most YAML errors are indentation errors. Indentation must use spaces, never tabs, and every key in a mapping (or item in a list) must start in the same column. A key indented one space too far is read as a continuation of the previous value, which produces messages such as "All mapping items must start at the same column" or "Nested mappings are not allowed in compact mappings".

Each error shows the line and column where the parser gave up, and Show me selects that spot in the input. When several errors are listed, fix the first one: the rest are often consequences of it. Unquoted values containing ": " or starting with characters such as @, `, % or * are another common cause; wrap them in quotes.

Most YAML that developers touch configures another tool: GitHub Actions and GitLab CI pipelines, Kubernetes manifests, Helm values, Docker Compose files, OpenAPI specs and Ansible playbooks. Each tool picks its own parser, which is why the same file can behave differently in two places. The JSON output shows exactly what a parser sees, with no ambiguity: a string has quotes, a number or boolean does not.

Converting also helps with tooling. jq, API clients and every language's standard library read JSON, so turning a manifest into JSON lets you query it, diff it or feed it to a script without a YAML dependency. In the other direction, JSON produced by a script or an API becomes readable YAML for a pull request.

Template syntax such as Helm's {{ .Values.image }} or a GitHub Actions expression like ${{ github.ref }} is not part of YAML; those tools expand it before or after parsing. The converter treats it as plain text, which is what you want when you are checking structure. Unquoted, a value that starts with {{ is read as a flow mapping and fails, which is why Helm charts quote such values.

Every JSON document is also valid YAML 1.2, so YAML tools can read JSON directly. Converting is about readability: block style with indentation, no braces and fewer quotes. Strings that would be misread as numbers or booleans stay quoted, so "02134" and "3.10" keep their meaning.

Numbers go through JavaScript, so integers above 9,007,199,254,740,991 lose precision; send large IDs as strings. Line width is unlimited, so long strings stay on one line instead of being folded. For typed code from the same payload, try JSON to TypeScript.