toolready. YAML ↔ JSON Converter

YAML ↔ JSON Converter

YAML ↔ JSON, both directions, with inline validation.

What this does

A two-pane YAML and JSON converter that validates as you type. Source on the left, result on the right, an error banner under both when the input won't parse. The direction buttons switch which is which; Indent picks 2 or 4 spaces for the output side; Output → Input moves the result across and flips direction, the quick way to round-trip a document. Parsing is js-yaml running in your browser, so a secrets-laden manifest stays on your machine.

How do I convert YAML to JSON?

  1. Leave the direction on YAML → JSON.
  2. Paste the document — indentation, lists, block scalars and anchors all welcome.
  3. Read the JSON on the right, or fix whatever the red banner names. Errors carry a line and column, e.g. tab characters must not be used in indentation (2:1).
  4. Copy output when it's clean.

Why did my version number change?

Because unquoted scalars are typed by pattern, and YAML's number pattern is greedy. A config that says version: 1.10 parses as the float 1.1 and lands in JSON as 1.1. The same surprise covers 0x1F (31), 0o17 (15), and integers past 253, which quietly lose their last digits. Worse, .inf and .nan parse fine in YAML but have no JSON equivalent, so they arrive as null. The fix never changes: quote anything that's a label rather than a quantity. 

version: 1.10          {
released: 2024-01-01     "version": 1.1,
country: NO         →    "released": "2024-01-01T00:00:00.000Z",
port: "8080"             "country": "NO",
                         "port": "8080"
                       }

Does a bare date survive the trip?

Not unchanged. js-yaml's default schema includes the timestamp type, so released: 2024-01-01 becomes a date object, and serialising it to JSON yields a full ISO string with a midnight-UTC time attached. Quote a calendar date — "2024-01-01" stays those ten characters.

Is "no" parsed as false here?

No, and the detail matters. The Norway problem comes from YAML 1.1, where no, yes, on and off are booleans and the country code NO therefore becomes false. js-yaml follows YAML 1.2, where only true and false (plus capitalised forms) are booleans, so all four stay strings here. That's no licence to leave them bare: PyYAML, Ruby's Psych and several Go parsers are still on 1.1, so a file that reads correctly here can still flip on the server. Note the JSON → YAML direction quotes them for you — a string "no" is emitted as 'no' so an older parser can't misread it.

Why does my multi-document YAML fail?

Because a stream of documents separated by --- has no JSON counterpart — JSON holds one value. Feeding one in raises expected a single document in the stream, but found more. Split it and convert each document separately, the usual case with a Kubernetes manifest bundle. Duplicate mapping keys are rejected too rather than last-one-wins, so a: 1 twice is an error here even though most JSON parsers accept the equivalent.

What else changes on the way through?

Comments are gone — JSON has none, so every # line disappears on the first pass. Anchors and aliases (&base, *base) and merge keys (<<:) resolve into duplicated structures. Going to YAML, block scalars are chosen for you: a string with newlines becomes a literal | block, a long single-line string folds with >- at around 80 columns. Empty values, ~, Null and NULL all collapse to one JSON null. To compare before and after, paste both into the text diff; for TOML too, JSON ↔ YAML ↔ TOML; to reformat JSON alone, the JSON formatter.