Fast, practical, browser-based developer tools
Convert YAML into JSON instantly in your browser, validate the input, and then format, copy, or download the output. This tool is useful for APIs, configuration files, deployment workflows, developer tooling, and structured data conversion.
YAML is widely used because it is compact, readable, and comfortable for configuration files. JSON is commonly required by APIs, applications, and many developer tools. This converter helps bridge those formats quickly so you can move configuration and structured data into workflows that expect JSON.
This YAML to JSON converter is designed to run in the browser using a YAML parsing library. That means the YAML text you paste is handled locally on your device during the conversion workflow instead of being uploaded as part of the tool’s normal operation.
For more details about site usage and analytics, read our Privacy Policy.
Paste your YAML into the input area and click Convert to JSON. If the syntax is valid, the parsed structure will be rendered as formatted JSON. You can then beautify the result again, copy it, or download it as a JSON file.
name: John age: 30 skills: - json - yaml
{
"name": "John",
"age": 30,
"skills": [
"json",
"yaml"
]
}
The signature hazard of reading YAML is that unquoted scalars get a type guessed for them,
and the guess is often not what you meant. In the widely used YAML 1.1 rules, the words
yes, no, on, off, true, and
false — in several capitalisations — all become booleans. So a list of country
codes containing NO for Norway turns into false in your JSON, and
[NO, SE, DK] becomes [false, "SE", "DK"]. This is the famous
Norway problem, and it corrupts data silently because the YAML was perfectly valid.
Numbers get the same treatment. 1.0 arrives as the number 1, a leading-zero
value may be parsed as octal, and 08 can even throw because 8 is not a valid
octal digit. The lesson for anyone writing YAML that will be converted: quote any string
that could be read as a boolean, number, or null.
"Valid YAML" is not one thing. YAML 1.1 and YAML 1.2 disagree about implicit types:
yes/no/on/off are booleans under 1.1 but plain strings under 1.2's core
schema. Python's PyYAML — the parser behind an enormous amount of tooling — still applies
1.1 semantics, whereas many JavaScript loaders lean toward 1.2. The same document can
therefore yield different JSON depending on which library reads it.
That matters here specifically: if this converter and your production parser disagree on a version, the JSON you preview may not match what your service actually produces. When the distinction is load-bearing, confirm the behaviour against the parser that will run in production, not just any converter.
YAML has no brackets — structure is defined entirely by indentation, which makes it readable and fragile in equal measure. Indentation must use spaces; a tab character in indentation is illegal and produces a parse error, so YAML copied from an editor that inserts tabs fails even though it looks aligned. A single misplaced space can silently move a key from one nesting level to another and change the resulting JSON without any error at all.
Duplicate keys are another quiet one. The YAML 1.2 spec says a mapping must not have
duplicate keys, but many parsers do not enforce it and simply keep the last value, so
{port: 80, port: 443} converts to a single "port": 443 with the
first silently dropped.
YAML is more expressive than JSON, so some constructs have to be collapsed on the way down.
Anchors and aliases (&name and *name) let a
block be defined once and referenced many times; converting to JSON expands every reference
into a full copy, which can multiply the output size — a deliberately nested version of this
is the "billion laughs" YAML bomb. Non-string keys are legal in YAML — a
mapping can be keyed by a number, a boolean, or even a sequence — but every JSON key must be
a string, so those keys get stringified. And YAML timestamps such as
2026-07-09 may parse as date values that become strings in JSON.
YAML 1.1 implicit typing reads those unquoted words as booleans, so Norway's country
code NO becomes false. Quote the value —
"NO" — to keep it a string through the conversion.
No. YAML forbids tabs in indentation and only accepts spaces, so a tab produces a parse error even when the file looks properly aligned. This is one of the most common reasons valid-looking YAML fails to convert.
Implicit typing again: 1.0 becomes the number 1, a leading-zero value can
be read as octal, and a large integer beyond 253 loses precision once it is
a JavaScript number. Quote values like IDs and versions that must stay exact strings.
JSON has no references, so every alias is expanded into a full copy of the anchored block. Heavily reused anchors can make the JSON much larger than the YAML, and maliciously nested ones are the basis of the "billion laughs" denial-of-service.
The spec says they should, but many parsers do not enforce it and keep the last value,
so {port: 80, port: 443} quietly becomes a single "port": 443.
Check for repeated keys if a field seems to have the wrong value.