How YAML to JSON Converter works
YAML and JSON describe the same data in two different styles: YAML is written for people to edit, JSON for machines to parse. This converter moves between them in both directions, handling the constructs that config files actually use — nested maps, sequences, quoted and bare scalars, inline comments and multi-line block text. It is deliberately careful about types, so a value such as 0755 or 1.2.3 stays a string rather than being silently mangled into a number. Because the conversion runs entirely in your browser, pasting a Kubernetes manifest or a CI pipeline containing internal hostnames does not transmit any of it.
Why type inference is the part that bites
YAML tries to guess what you meant, and the guesses are the source of most real-world surprises. The best-known example was the Norway problem: an unquoted NO was read as the boolean false, so a list of country codes quietly lost Norway. Version numbers are another trap, since 1.2 parses as a number while 1.2.3 stays a string, meaning two adjacent lines in the same file behave differently. A leading zero on something like 0755 is a third, because in some parsers it becomes an octal number rather than the permission string you meant. This converter takes the conservative route: only a clean canonical number — no leading zeros, no trailing dots, no version-style extra segments — is converted to a number, and everything else stays a string. When you want a value to be unambiguously text, quoting it is always the reliable answer, and quoting is never wrong even where it is unnecessary.
What this converter supports, and what it does not
The supported subset is the one that config files in the wild actually use: nested mappings, sequences including sequences of maps, quoted and bare scalars, numbers, booleans, nulls, comments, flow collections written inline with brackets or braces, and block scalars introduced with a pipe or a greater-than sign. Deliberately out of scope are anchors and aliases (&name and *name), which let a YAML document reference a block defined elsewhere; explicit type tags such as !!str; and multi-document streams, where several documents are separated by a line of three dashes. These appear mostly in hand-tuned Helm charts and Docker Compose files that lean on YAML's more advanced features. If your file uses them, resolve those references first or reach for a full YAML library — a converter that pretended to handle anchors while quietly dropping them would be worse than one that is honest about the boundary.
Step by step
- 1
Choose the direction — YAML to JSON, or JSON to YAML.
- 2
Paste your configuration into the input box.
- 3
Pick the indentation width you want in the output.
- 4
Copy or download the converted file. If a line will not parse, the error names the line number responsible.
When you would reach for this
Reading a Kubernetes manifest
Converting a manifest to JSON makes the nesting explicit, which is often the fastest way to see why a field is landing at the wrong level.
Moving config between tools
One tool wants YAML and another only accepts JSON. Converting is quicker and less error-prone than retyping a structure by hand.
Debugging a CI pipeline
When a GitHub Actions or GitLab CI file behaves unexpectedly, seeing it as JSON reveals whether a value parsed as a string, a number or a boolean.
Writing JSON by hand
YAML is far more comfortable to type — no quotes around keys, no trailing-comma errors — so drafting in YAML and converting to JSON is often the faster route.
Practical notes
- YAML forbids tab characters for indentation. If a file will not parse and looks fine, check for tabs first — the error message here names the line.
- Quote any value that could be read as something else: version numbers, country codes, times such as 09:30, and anything with a leading zero.
- JSON is valid YAML, so a YAML parser will happily accept JSON input — useful when a tool claims to want YAML but you already have JSON.