YAML to JSON Converter

What the YAML to JSON converter does

The converter reads YAML by the core schema of YAML 1.2 (opens in a new tab) and writes the same data as JSON, so you can hand a configuration file to an API, a JSON tool or your code, or simply see what a parser makes of it. JSON has no comments, anchors, tags or multiple documents per value, so the converter expands, reshapes or drops those, and the Problems list says where. Numbers are copied digit for digit, and YAML's own forms, like 0x1F, are converted to exact decimal values.

How to convert YAML to JSON

Examples

base: &base
  timeout: 30
  retries: 3
fast:
  <<: *base
  timeout: 5

{
  "base": {
    "timeout": 30,
    "retries": 3
  },
  "fast": {
    "timeout": 5,
    "retries": 3
  }
}

answer: no
mode: 0644
window: 1:30

{
  "answer": "no",
  "mode": 644,
  "window": "1:30"
}

Bucket: !Ref LogsBucket
Mask: 0xFF

{
  "Bucket": "LogsBucket",
  "Mask": 255
}

Anchors, aliases and merge keys

An anchor (&name) labels a value, and an alias (*name) repeats it elsewhere in the same document. JSON has no references, so every alias is replaced by a full copy of the anchored value. An alias takes the last value with its name before it; one that comes before its anchor, or sits in another document, is an error.

A merge key, <<, copies the keys of a mapping into the mapping it appears in, which is how Docker Compose files share settings between services. The merged keys take the place of the << line, and three rules decide which value wins:

• a key written in the mapping itself beats a merged one, wherever it stands;
• with a list, as in <<: [*defaults, *logging], an earlier mapping beats a later one;
• a merged mapping brings its own merges along.

Merge keys come from YAML 1.1 and are not part of YAML 1.2, but most parsers still support them. Turn off Resolve merge keys to see << as an ordinary key holding the other mapping.

Copies multiply when aliases point to values that contain more aliases: nine levels of nine aliases each, the "billion laughs" pattern, would make a document of billions of values from a few lines of YAML. The converter therefore stops after 10,000 aliases or 1,000,000 values written through them, far more than any real configuration file uses.

Several documents in one file

A line of three dashes, ---, starts a new document, which is how Kubernetes keeps several manifests in one file. JSON holds one value, so documents become the items of a JSON array by default. Choose JSON Lines to get one compact document per line instead, the format that jq -c and many log tools read. A document with no content, such as a --- at the very end of the file, becomes null. A file with a single document is written as that document's value, whatever this option says.

YAML 1.1 and the Norway problem

YAML 1.1, published in 2005, read many plain words and numbers differently from YAML 1.2. In 1.1, the country code NO is the boolean false, which is why this pitfall is called the Norway problem. The converter follows YAML 1.2 and warns about every unquoted value that YAML 1.1 reads otherwise:

• the YAML 1.1 booleans (opens in a new tab) y, n, yes, no, on and off, in lowercase, capitalized or uppercase;
• numbers with a leading zero, which are octal in 1.1: 0644 is 644 in YAML 1.2 but 420 in YAML 1.1;
• times like 1:30, which 1.1 reads as a base-60 number, 90;
• digits grouped with underscores, like 1_000, and binary numbers like 0b101;
• dates like 2024-01-01, which 1.1 reads as a timestamp;
• YAML 1.2 number forms that 1.1 reads as text, such as 1e3 and 0o755.

The warning matters when another program reads the same file. PyYAML, which Ansible uses, still follows YAML 1.1, like many parsers written before YAML 1.2 appeared in 2009. Quoting a value makes it a string in every version: "NO" is safe everywhere.

Custom tags like !Ref

A tag, written with an exclamation mark, tells a program how to build a value. AWS CloudFormation uses !Ref, !Sub and !GetAtt; YAML 1.1 defined !!binary, !!set and !!omap. JSON has no tags, so the converter writes each value with its own structure, a scalar as a string and a mapping as an object, and warns at the tag. The tag's meaning is lost: !Ref LogsBucket becomes the plain string "LogsBucket", which CloudFormation would not resolve. The core tags !!str, !!int, !!float, !!bool, !!null, !!map and !!seq work as they say, so !!str 123 gives the string "123".

Comments are left out

JSON has no syntax for comments, so the converter drops every # comment and reports how many there were. Keep the YAML as the file you edit when its comments matter. If a note must travel with the data, move it into a value, such as a description key that the program reading the JSON ignores.

Hex, octal, .inf and .nan

YAML 1.2 has number forms that JSON does not, and the converter turns them into JSON numbers of exactly the same value: 0x1F becomes 31 and 0o755 becomes 493, computed with arbitrary precision so a long hex value keeps every digit. +1 becomes 1, .5 becomes 0.5 and 1. becomes 1.0. Numbers that JSON already allows, like 1e3 or 12345678901234567890, are copied as written. A whole number above 9,007,199,254,740,991 gets a note, as most JSON readers round it; the JSON Formatter explains why.

.inf, -.inf and .nan have no JSON form at all. By default they stop the conversion; set .inf / .nan values to String to keep them as text, or to null.

Options

Common errors and fixes