Converted result will appear here...
Convert between YAML and JSON formats with syntax highlighting.
The tool is a two-way bridge between YAML and JSON. YAML to JSON runs the text through js-yaml’s load and then JSON.stringify with two-space indentation. JSON to YAML runs JSON.parse and then js-yaml’s dump, also with two-space indentation. Everything happens in the browser tab; the page does not need a network call once it has loaded. Syntax errors are reported with a line number, so a message like “at line 4” points straight at the offending indentation or character. The panel also offers copy and download so you can move the result into a file.
YAML scalars are untyped text, and the parser decides after the fact whether each one is a string, number, boolean, null, or timestamp. That guess is where most conversion bugs begin, because the same characters can resolve to different types in different parsers.
| You write | Parsed as here | Surprise |
|---|---|---|
version: 1.10 | number 1.1 | Trailing zero lost |
zip: 01234 | number 1234 | Leading zero lost |
country: NO | string "NO" | YAML 1.1 parsers would read false (the Norway problem) |
enabled: yes | string "yes" | YAML 1.1 parsers would read true |
flag: True | boolean true | Case does not matter for true and false |
count: 1e3 | number 1000 | Scientific notation is a number |
id: 12345678901234567890 | rounded number | Precision lost above 2^53 |
big: .inf | Infinity, then null | JSON cannot express it |
The lesson is not that YAML is broken but that unquoted scalars carry meaning. The Norway problem is the canonical example: a country code written as NO is a string to a YAML 1.2 parser and a boolean false to a YAML 1.1 parser. When two systems disagree about the schema, the data changes meaning silently.
Consider this input:
service: checkout
version: 1.10
retries: 3
enabled: yes
region: NO
The JSON output is:
{
"service": "checkout",
"version": 1.1,
"retries": 3,
"enabled": "yes",
"region": "NO"
}
Two things went wrong silently. The version lost its trailing zero, and enabled and region are strings that anyone reading the file would assume were a boolean and a country code. The corrected YAML quotes the ambiguous values:
service: checkout
version: "1.10"
retries: 3
enabled: "yes"
region: "NO"
Now no parser anywhere can reinterpret them.
Quoting is the primary tool. Double quotes are the most portable; single quotes also work and are what the YAML dumper emits when it needs to protect a string. You can also be explicit with a tag such as version: !!str 1.10. When converting JSON back to YAML, the dumper does this work for you: a JSON string "yes" is written as 'yes' and a string "1.10" as '1.10', precisely so that re-reading the YAML does not turn them into a boolean or a number. That is why a JSON to YAML to JSON round trip preserves string values correctly.
--- separator produces an error; convert sections separately.The two formats overlap heavily, so the choice is usually about who edits the file and how strict the consumer is. YAML is pleasant to write by hand: it supports comments, omits most brackets and braces, and handles multi-line strings with block scalars. Its cost is indentation sensitivity and the type guessing described above. JSON is unambiguous and supported by nearly every language and API, but it has no comments, requires quoted keys, and rejects trailing commas.
| Situation | Better choice |
|---|---|
| Hand-edited configuration with comments | YAML, with quotes around ambiguous strings |
| API request or response body | JSON |
| Data crossing language boundaries | JSON, because its types are fixed |
| Configuration consumed by a YAML 1.1 tool | YAML, but quote anything that could be a boolean |
| Values that must keep leading zeros or trailing decimals | Either, but quote the values |
A practical rule: use YAML where humans write and review, use JSON where machines exchange, and quote any string that a parser might mistake for a number or a boolean.
A second worked example shows how the dumper protects strings on the way back from JSON. Take this input:
{"name":"web","replicas":3,"enabled":true,"version":"1.10","labels":["prod","eu"]}
The YAML output is:
name: web
replicas: 3
enabled: true
version: '1.10'
labels:
- prod
- eu
Three details are worth noticing. The number 3 is written bare because it is a genuine number, while true is written bare because it is a genuine boolean. The string "1.10" is written as '1.10' with quotes, because the dumper knows that an unquoted 1.10 would come back as the number 1.1. The array becomes an indented block list rather than bracket notation, which is the dumper’s default style. Indentation is two spaces throughout.
YAML has no explicit number type, so the parser guesses. The scalar 1.10 looks like a floating-point number, and when it is parsed into a JavaScript number the trailing zero is not significant, so 1.10 and 1.1 become the same value. The JSON output then prints 1.1. If the version must stay intact as text, quote it in the source: version: "1.10". Quoting tells the parser to treat the characters as a string and the value survives the round trip.
Not here. This converter uses js-yaml's default core schema, in which only true and false (in any letter case) are booleans, so NO is read and written as the string "NO". The famous Norway problem belongs to YAML 1.1 parsers such as some versions of PyYAML, which treat unquoted NO, yes, on, and off as booleans. Because the same file can mean different things in different tools, the safe habit is to quote any string that could be mistaken for a boolean.
JSON has no comment syntax, so comments cannot be represented in the JSON output and are discarded when the YAML is loaded. If preserving the comments matters, keep the original YAML file and treat the JSON as a derived artifact. Converting back from JSON to YAML will not restore them, because the information was never stored in the parsed data.
No. The converter loads a single document, and a YAML stream that contains more than one top-level document is rejected with an expected a single document error. Split the file at each --- separator and convert the sections one at a time, or use a script that calls a multi-document loader.
No, not beyond JavaScript's safe integer range of 2^53 - 1. A value such as 12345678901234567890 is parsed into a double, which can only represent it approximately, and the JSON output shows the rounded number. If you need an identifier like a long account number or snowflake ID to survive, put it in quotes so the parser treats it as a string.
YAML can represent positive infinity, negative infinity, and not-a-number, and the parser loads them as JavaScript Infinity and NaN. JSON has no way to write those values, so the serializer renders them as null. If those values matter, keep the data in YAML or replace them with a sentinel string before serializing.
Reviewed by the HandyTools Hub team · Last updated