Convert YAML to JSON

YAML 1.2 is deliberately a superset of JSON, which means every JSON document is already valid YAML and this conversion is a matter of writing the same data with none of the shorthand. That is exactly why it is useful for debugging: the JSON shows you the values the parser produced, not the characters you typed.

Most of the surprises in a YAML file are resolution surprises — a version that became a number, a word that became a boolean, an alias that pulled in more than you expected. None of them are visible in the YAML and all of them are visible in the JSON. The rest of this page is the list of those resolutions, in the order they tend to cost people time.

YAML files can hold several documents in one stream, separated by --- lines. Kubernetes manifests use that constantly: a Deployment, a Service and a ConfigMap in one file is the normal shape. JSON has no equivalent — a JSON file is one value — so the parser refuses rather than silently picking a document, and the conversion fails with a message naming the line where the second document begins.

The workaround is mechanical. Split the file at the --- markers and convert each document separately, or wrap the parts in a single top-level list yourself before converting. A leading --- on its own at the top of a file is fine and so is a closing ... marker; it is only a second document that stops it.

An anchor and its aliases collapse into copies. A .gitlab-ci.yml that defines &defaults once and aliases it from six jobs produces JSON with six full copies of that block, because JSON has no way to refer to a value defined elsewhere. The output is larger than the input and says the same thing.

The merge key is the part that catches people. A line written << followed by an alias is a YAML 1.1 convention for merging a map into the current one, and it is not part of the YAML 1.2 core schema, so it comes through as an ordinary key named "<<" whose value is the referenced map. The keys you expected to be merged into the job are one level down under that key instead. Whatever consumes the JSON has to flatten it, and you should assume any tool downstream will not.

CloudFormation short forms, Home Assistant includes and a dozen other dialects hang meaning off custom tags: !Ref myBucket, !GetAtt [resource, attribute], !include other.yaml. The parser does not know those tags, so it resolves each one to its bare value and moves on — !Ref myBucket becomes the plain string "myBucket", and !GetAtt with a list after it becomes just the list.

This is the most dangerous conversion on the page, because the JSON is valid, plausible and wrong. There is no marker left to say a tag was there. If your YAML belongs to a dialect with custom tags, this converter will produce a document that no longer describes what you meant, and the only defence is knowing in advance that your file uses them.

YAML 1.1 treated yes, no, on, off, y and n as booleans, which is the origin of the well-known problem where a country code written as no becomes false. The parser here implements YAML 1.2, whose core schema recognises only true and false, so those words survive as strings and the country code is safe.

That is a default, not a guarantee. A file whose first line is a %YAML 1.1 directive is read as 1.1, and then on genuinely does become true in the JSON. It is also only true of this converter — the tool that reads your YAML in production may well be PyYAML, which is a 1.1 implementation. The JSON here tells you what a 1.2 parser sees, which is useful precisely because it may differ from what your runtime sees.

A value written 1.0 resolves to the number 1, so a pinned version becomes an integer and prints without its decimal. A value written 0755 resolves to 755. Quoting either one in the source keeps it a string, and the JSON output will show quotes around it, which makes this conversion a quick way to audit a file for values that need quoting.

Large integers lose precision silently. YAML has no size limit on an integer, JSON numbers are IEEE doubles, and a 64-bit identifier written 9223372036854775807 comes out as 9223372036854776000. Nothing reports it. Any YAML holding IDs of that magnitude wants them quoted as strings before conversion, not after.

JSON has six types and YAML has a tag system. Where the two disagree, something is flattened. A value carrying the explicit !!timestamp tag becomes a date and then an ISO 8601 string in the JSON, normalised to UTC — so a timestamp written with a minus five hour offset comes out shifted and marked with a Z, and the original offset is gone.

A !!binary value is decoded to bytes and then serialised as an object keyed by position — the two bytes of "hi" arrive as {"0":104,"1":105}. The data is all there and no consumer will recognise it; re-encoding the field to base64 text in the YAML before converting is the shorter road. Unquoted dates without a tag are simpler: under the 1.2 core schema they are ordinary strings, so a date written 2024-01-02 stays the string 2024-01-02, which is usually what you want.

Two errors stop the conversion outright and both are worth recognising. Duplicate keys in the same mapping are rejected — the message is that map keys must be unique, with the line number — which is stricter than some YAML tools and generally the correct behaviour, since a duplicate key means one of the two settings has been ignored ever since it was added.

The second is a tab used for indentation. YAML forbids tabs there, and the parser says so with a line and column. Both errors are the converter doing you a favour: a file with either problem is a file whose behaviour already depends on which parser reads it.

The output is indented two spaces and ends with a newline, so jq, a JSON Schema validator and any HTTP client read it directly. Validation is the strongest reason to make this trip: JSON Schema is mature and widely implemented, and running a generated JSON copy of a config through a schema catches misspelled keys that a YAML linter, which only checks syntax, will pass.

It is not a replacement for the YAML. Comments are gone, anchors are expanded into duplication, and any custom tags have quietly evaporated, so converting back would give you a file that works and no longer reads like something a person wrote. Keep the YAML as the source and treat the JSON as the view.