How to check a YAML file and read its JSON preview

Paste a YAML configuration into the box and press Validate. The check runs in the browser — nothing is uploaded — and answers with one line per problem: tab indentation and a key repeated inside one mapping are errors, trailing spaces are notes, and anchors, merge keys and tags are marked as advanced YAML that needs a full parser.

The parsed document appears beside the report as JSON, above the line count, the number of parsed values, the issue count and the input size. Copy puts that JSON on the clipboard and Download saves it as validated-yaml.json; both answer with a note until a run has produced something.

  1. Paste the YAML text. The page has no file picker, so a file on disk has to be opened in an editor and pasted — or start from Load example, a ten-line service definition.
  2. Press Validate. The example reports 10 lines, 10 parsed values and 0 issues; a 2,401-line document is still parsed in about six milliseconds.
  3. Read the validation report under the preview: every entry starts with its line number, errors are marked red and notes such as trailing whitespace amber.
  4. When a parsing error is reported, the JSON pane stays empty — fix the line named in the message and validate again.

What the preview does with each value

Duplicate keys, indentation and whitespace

A key written twice inside the same mapping is an error, and the message names the line of the second one: host twice under server: reads 2: duplicate key "host"., and an inline map such as {a: 1, a: 2} is caught the same way. A field that repeats once per record is not a duplicate — the same - name: entry under three rules items is not reported, because every list item opens a mapping of its own.

Tab indentation is an error on each line that uses it and trailing spaces are noted line by line; both cover the whole document in one run. The parser itself stops at the first fault, so a document with several syntax errors shows one parsing message at a time.

How values are read

Mappings, sequences, inline [1, 2] and {a: 1} values, comments, quoted keys, single- and double-quoted strings (a double-quoted \n becomes a line break) and the literal | and folded > blocks are read as the file intends. The preview keeps JSON types apart: 42 and 0.5 are numbers, true, yes and off are booleans, null, ~ and an empty value become null, and 2026-08-29 stays text.

Spelling decides the type, so 007 and 0755 keep their leading zeros as text, 0xFF and 1.2.3 stay text, and 1.10 is read as the number 1.1. An unquoted 20-digit account number is read as a number and changes in its last digits (12345678901234567890 previews as 12345678901234567000), so an id, a version or an account number that has to survive the round trip belongs in quotes.

Where the subset parser stops

Merge keys are kept for review instead of being expanded: <<: *base stays in the preview as a literal key and its line is reported. A second document after ---, a line that is not a key: value mapping, an inline list that is never closed with ], an unterminated quoted string and an alias whose anchor was never defined are reported as errors with their line number, and no JSON is shown until they are fixed.

Recent tools: