YAML to JSON Converter: Convert in Your Browser

YAML and JSON describe the same kind of data, which is why converting between them looks trivial. The trouble sits in the details. YAML allows comments, anchors, several documents in one file and a loose notation for values, and it decides what a bare word means by rules that changed between versions. JSON has none of that. A converter has to pick a rule for each gap.

This converter reads YAML with the library yaml in the browser, treats the input as YAML 1.2 and writes JSON. The text stays in the open tab and is not sent to a server. The sections below state what happens at the points where the formats differ.

How to convert YAML to JSON online

1. Paste the YAML into the input field, or start from the example.
2. Start the conversion. The JSON appears in the output field.
3. If the YAML is invalid, the page shows the error with its line and column. Fix the first reported problem and convert again, since indentation mistakes often cause follow-up messages.
4. Copy the JSON. Look closely at values such as dates, country codes and version numbers, which are the ones that tend to change type.

The line and column in an error point to the place where the parser gave up, which is not always the place where the mistake began. A wrong indent on one line can surface as a complaint a few lines later, so it helps to look at the lines above the reported position as well.

Indentation is the most common cause of errors. YAML uses spaces to express structure, and a single misplaced space can turn a nested value into a sibling or make the file unreadable.

YAML values that change type in JSON

In JSON, a value is a string, a number, a boolean, null, an object or an array (RFC 8259, section 3). In YAML, a plain value such as no or 2001-12-14 is only text on the page until a schema rule gives it a type. The YAML 1.2.2 specification defines the Core schema in section 10.3.2: true and false (also capitalized) are booleans, null, Null, NULL, ~ and an empty value are null, integers and floats have fixed patterns, and everything else is a string. YAML 1.1 used a wider list. This page applies the 1.2 rules.

The 1.1 column comes from the type definitions at yaml.org, whose boolean type lists y, yes, n, no, true, false, on and off in several capitalizations, and from a run with PyYAML 6.0.3, which follows the 1.1 rules. That run also shows why the difference matters. A list of country codes written as [DE, NO, SE] came back as ['DE', False, 'SE'], because Norway's code is a boolean in YAML 1.1. A 1.2 parser keeps it as the string "NO". The Core schema of YAML 1.2 defines no timestamp type, so a date stays a string.

Quoting is the dependable way to keep a value as text. A value in quotes is a string in every YAML version, so "NO" stays a country code even when the file is read by a parser that follows the older rules. The same holds for version numbers and postal codes with a leading zero. When a file is shared between tools, quoting such values removes the dependence on the YAML version.

Two values cannot be written in JSON at all. RFC 8259 section 6 does not allow Infinity and NaN, so .inf and .nan have no direct counterpart, and the output for them should be checked. Very large integers need care too. The RFC says good interoperability comes from implementations that expect no more range and precision than IEEE 754 binary64, and in a test the JavaScript function JSON.parse turned 9007199254740993 into 9007199254740992, while Python kept the exact number.

Anchors and aliases become copies

YAML lets a value be marked once with an anchor, written &name, and reused later with an alias, written *name. The specification treats the anchor name as a serialization detail that is not kept in the data. JSON has no such reference, so every alias turns into a full copy of the value.

defaults: &defaults
  retries: 3
copy: *defaults

This becomes an object with a defaults key and a copy key that both hold {"retries": 3}. The JSON is correct and larger, and for a file with many references the growth can be large. The link between the two places is gone, so a later edit of one copy does not change the other.

A related feature is the merge key <<, which copies the pairs of one or more mappings into another. It is defined in the YAML 1.1 type definitions, and the YAML 1.2.2 specification does not mention it. Whether a parser expands it therefore depends on the parser and its version, and a file that relies on merge keys should be compared with its JSON result.

Multiple YAML documents in one file

A YAML stream can hold several documents, each independent of the others. Three dashes start a document, and three dots end one without starting the next (sections 9.1 and 9.2 of the specification).

name: first
---
name: second

A JSON text is a single serialized value, as RFC 8259 section 2 puts it. Two documents therefore cannot become one JSON text without a rule: an array that holds them, only the first one, or an error are the usual choices. A file with more than one document should be checked against the number of separators it contains. When one JSON value per document is needed, converting the documents one at a time is the clearest route.

Comments, complex keys and ordering

Comments have no effect on the data in YAML (specification section 3.2.3.3), and the JSON grammar has no place for them, so they are dropped. A note such as a warning above a setting does not travel into the JSON.

Keys are the second gap. YAML allows any node as a key, including a list or a mapping, written with a leading ?. A JSON name is always a string. A key that is not text has no name to become, and a parser may refuse the file; PyYAML raised an error for a sequence used as a key. Keys inside one mapping are meant to be unique in YAML, and RFC 8259 says names in an object SHOULD be unique and warns that behavior with duplicates is unpredictable. PyYAML kept only the last of two equal keys without any message, which hides data, so duplicates are worth removing in the source.

Order is the last point. The specification describes a mapping as an unordered set of pairs and treats key order as a serialization detail, and a JSON object is unordered in the same way. Anything that depends on the order of keys should use a list instead.

YAML vs JSON

The conversion limits double as a short comparison of the formats.

YAML 1.2 set out to be a strict superset of JSON (section 1.2 of the 1.2.2 specification), so valid JSON should be valid YAML. That is a goal of the specification and not a promise from every parser. In a test, PyYAML read the JSON number 1.5e3 as text and rejected a tab after a colon, although JSON allows both.

For the same question applied to XML, see XML vs JSON. XML input has its own rules on the XML to JSON converter, and the XML formatter checks that a document is well-formed first.

How the converter is defined

The page uses the JavaScript library yaml and reads input as YAML 1.2, so the Core schema decides the type of each plain value. Errors carry line and column. The comparison runs for YAML 1.1 behavior used PyYAML 6.0.3 as a reference, which is a different parser and behaves differently from this page. The conversion makes no network request. It runs in one direction, from YAML to JSON, and the points in which JSON cannot hold what YAML expresses are the ones listed above.