Converters

How to Convert YAML to JSON (Types, Indentation and Quoting Explained)

How to convert YAML to JSON: how mappings, sequences and indentation map onto objects and arrays, how each value is typed, why unquoted numbers change, and which YAML features aren't supported - with a worked example.

5 min readUpdated Jul 23, 2026

YAML - "YAML Ain't Markup Language" - is the human-friendly format that configuration lives in: Docker Compose files, Kubernetes manifests, CI pipelines and app settings are almost all YAML. It is easy to read and write because structure comes from indentation rather than brackets. JSON - JavaScript Object Notation - is the machine-friendly format that APIs, tooling and JavaScript expect, with explicit braces, real numbers and booleans, and no reliance on whitespace. Converting YAML to JSON means translating that indented, comment-friendly text into the strict, bracketed structure a program can parse directly. This guide explains how the YAML to JSON converter maps one onto the other, how it decides the type of each value, and walks through a worked example you can reproduce.

How YAML maps onto JSON

The two formats describe the same three building blocks, just with different punctuation. A YAML mapping - a set of key: value lines - becomes a JSON object. A YAML sequence - a list of dash-prefixed items - becomes a JSON array. And a plain value on the right of a colon becomes a JSON scalar: a string, number, boolean or null. The one thing YAML does that JSON does not is use indentation to show nesting. Where JSON opens a brace or bracket, YAML simply indents the child lines further to the right. The converter reads that indentation, works out which lines belong inside which block, and rebuilds the nesting with the braces and brackets JSON requires.

How values are typed

YAML has no quotes around most values, so the converter has to infer a type from the text of each scalar. It follows the rules people expect:

  • A run of digits like 8080 becomes a JSON number, and a value with a decimal point like 19.99 becomes a floating-point number.
  • The words true and false - in any case, so true, True or TRUE - become JSON booleans.
  • An empty value, a tilde (~), or the word null becomes JSON null.
  • Anything else - db.internal, web-server, a whole sentence - stays a string, whether or not it is wrapped in quotes in the source.

One deliberate choice is worth calling out: only true and false are read as booleans. The words yes, no, on and off stay ordinary strings. That sidesteps the notorious "Norway problem", where a naive YAML parser turns the country code NO into the boolean false - here, NO stays the string it looks like.

A worked example

Take this small service configuration in YAML - top-level settings, a dash-prefixed list, and a nested block:

  • name: web-server
  • port: 8080
  • enabled: true
  • maintainer: null
  • tags:
  • - production
  • - critical
  • database:
  • host: db.internal
  • port: 5432
  • ports: [5432, 5433]

Paste it into the YAML to JSON converter and you get this JSON back: { "name": "web-server", "port": 8080, "enabled": true, "maintainer": null, "tags": ["production", "critical"], "database": { "host": "db.internal", "port": 5432, "ports": [5432, 5433] } }

Walk through what happened. The top-level key: value lines became an object. port 8080 came through as a real number rather than the string "8080", and enabled as a real boolean. maintainer: null became JSON null. The dash-prefixed tags list turned into an array of two strings. The indented database block, sitting one level to the right, became a nested object - and inside it, the inline ports: [5432, 5433] shows both writing styles working together in a single file.

Block style and flow style

YAML lets you write collections two ways, and the converter handles both. Block style is the indented, one-item-per-line form used for tags and database above - the readable default for hand-written config. Flow style is the compact, JSON-like form on a single line: an array as [5432, 5433] and an object as {cpu: 2, memory: 512}. Flow style is handy for short lists and pairs, and because it already looks like JSON it converts one-to-one. You can even paste a whole document written in flow style - the converter treats a lone [ ... ] or { ... } as the entire value.

Quoting: when a value must stay a string

Because unquoted numbers are converted to real numbers, a value that only looks like a number can change on you. An identifier such as 0074 is read as the integer 74 - the leading zero is dropped - and a version written as 1.20 becomes 1.2. Whenever a value is really a label rather than a quantity - a ZIP code, a SKU, a phone number, a zero-padded ID, a version string - wrap it in quotes: "0074" and "1.20" then stay exactly as written. Quoting is also how you keep a value that contains a colon, or one you want to remain the literal text true, from being reinterpreted. When in doubt, quote it: a quoted number you genuinely wanted as a number is easy to spot and fix, but a silently corrupted ID is not.

Common reasons a conversion fails

YAML's reliance on whitespace makes indentation the usual culprit when something breaks.

  • Use spaces, never tabs. YAML forbids tab characters for indentation, and mixing tabs with spaces is the most common cause of an "unexpected indentation" error - set your editor to insert spaces.
  • Keep each level's indentation consistent. Every key inside the same block must line up in the same column; a stray extra space shifts a line into the wrong block.
  • Close your quotes. An opening quote with no closing partner leaves the parser reading far past where you intended.
  • Advanced YAML is out of scope. Anchors and aliases (& and *), explicit tags (!!str, !!int) and multi-line block scalars (| and >) are not supported - the converter targets the common subset real config files use. Simplify those to plain values first.

It runs entirely in your browser

Configuration files often hold secrets - connection strings, hostnames, tokens - so where the conversion happens matters. The YAML to JSON converter parses everything inside your browser tab; nothing is uploaded to a server, and you can convert a sensitive manifest without it leaving your machine. Once you have JSON, the JSON Formatter will validate and pretty-print it, and the JSON to CSV converter can flatten a list of records into a spreadsheet if you need it in tabular form.

Frequently asked questions

Why did my version number, ZIP code or ID change after converting?
Unquoted values that look like numbers are converted to real numbers, so 0074 becomes 74 (the leading zero is dropped) and 1.20 becomes 1.2. When a value is a label rather than a quantity - a ZIP code, SKU, phone number, zero-padded ID or version string - wrap it in quotes in the YAML, e.g. "0074", and it will stay the exact string you typed.
Does it support anchors, tags and multi-line block scalars?
No. The converter covers the common subset of YAML that real config files use - indentation-based mappings and lists, nested blocks, inline (flow) arrays and objects, quoted strings, numbers, booleans and null. Advanced features such as anchors and aliases (& and *), explicit tags (!!str) and block scalars (| and >) are not supported; simplify them to plain values before converting.
Is my YAML uploaded anywhere?
No. The conversion runs entirely in your browser - the YAML you paste never leaves your device, which matters because config files often contain hostnames, connection strings and other secrets.