GetHubApps Logo
GetHubApps
📜
DeveloperFree · In-Browser

YAML to JSON Converter

Convert YAML to JSON and back, with indentation and lists handled for you.

JSON

{
  "name": "gethubapps",
  "version": 1,
  "features": [
    "calculators",
    "converters",
    "developer tools"
  ],
  "author": {
    "name": "Ada",
    "active": true
  }
}

Supports nested mappings, lists, quoted strings, numbers, booleans and flow-style [...] / {...} — not anchors, multi-document files, or multi-line block scalars.

Convert YAML to JSON and back, with validation on both sides — the conversion you need constantly when moving between config files that use YAML and APIs or tools that expect JSON.

YAML is a superset of JSON, so any valid JSON is already valid YAML. The interesting direction is the other one, where YAML's anchors, multi-line strings and type inference have to be resolved into plain JSON.

YAML features that JSON has no equivalent for

  • Comments (#) — stripped entirely on conversion to JSON, and unrecoverable.
  • Anchors and aliases (&name / *name) — resolved and expanded into duplicated values.
  • Multi-line block scalars (| preserves newlines, > folds them) — become single JSON strings with escaped newlines.
  • Multiple documents in one file (--- separators) — JSON has no equivalent, so each document must be converted separately.
  • Implicit typing — an unquoted value is guessed to be a string, number, boolean or null.

The Norway problem, and other type-inference traps

In YAML 1.1, the unquoted value `no` parses as the boolean false. So a list of country codes containing NO — Norway — silently becomes `false`. This is real enough to have its own name, and it is the single best argument for quoting strings in YAML.

YAML 1.2 narrowed the boolean set to true/false, but many widely used parsers still follow 1.1 behaviour. The safe habit is to quote anything you mean as a string, particularly if it looks like a boolean, a number, a date, or a version.

Unquoted YAMLParses asProbably meant
nofalse (YAML 1.1)The string "no"
yes, on, offbooleansStrings
1.20the number 1.2The version "1.20"
12:30sexagesimal 750 (YAML 1.1)A time string
2026-09-17a date objectA date string
null, ~nullSometimes the literal text

Indentation rules

  • Tabs are forbidden for indentation. A tab anywhere in the leading whitespace is a parse error — and an invisible one.
  • Indentation must be consistent within a block, though the number of spaces is up to you. Two is the common convention.
  • List items under a key may be indented or aligned with the key; both are valid, which is a frequent source of confusion.
  • A colon in an unquoted value breaks parsing, because it looks like a key separator. Quote anything containing `: `.

Frequently asked questions

Is every JSON file also valid YAML?
Yes — YAML 1.2 is a strict superset of JSON, so any valid JSON document can be parsed by a YAML parser. The reverse isn't true.
What happens to my comments when converting to JSON?
They're discarded. JSON has no comment syntax, so comments are lost permanently in the conversion — keep the YAML as your source of truth.
Why did my value 'no' turn into false?
YAML 1.1 treats no, yes, on and off as booleans. Quote the value — "no" — to keep it a string. This bites hardest with country codes, where NO means Norway.
Can I use tabs to indent YAML?
No. Tabs are not permitted as indentation and produce a parse error. Configure your editor to insert spaces in .yaml files.
How are YAML anchors handled?
They're resolved and expanded, so the JSON output contains the full duplicated value wherever the alias appeared. The reference itself can't be represented in JSON.

Related tools