YAML Formatter & Validator

YAML uses indentation (spaces) to define document structure and nesting — there are no curly braces or closing tags like in JSON or XML. An element's indentation level determines whether it is a child of the element above it or a sibling. One extra or missing space can completely change the meaning: a key that should be a sub-property of a service definition might become a top-level key instead, often without any error message from the YAML parser. This is why YAML errors are notoriously hard to debug — the symptom (wrong configuration) can be far from the cause (a stray space on line 47).

No. The YAML specification explicitly prohibits tab characters for indentation. Tabs are allowed inside quoted strings, but never as indentation. If your editor is set to insert tabs when you press Tab, switch it to insert spaces for YAML files. Many YAML-related bugs are caused by invisible tabs in files that look correctly indented. This formatter detects and normalizes tab indentation to spaces.

The formatter handles the complete YAML 1.2 feature set: scalar types (strings, integers, floats, booleans, null), block mappings (key: value), block sequences (- item), flow style (inline {} and []), multiline strings (literal block | and folded block >), comments (#), anchors (&anchor) and aliases (*alias), multiple documents (--- separator), and explicit type tags (!!str, !!int, etc.). Complex nested structures like Kubernetes pods with volumes, env arrays, and resource limits format correctly.

Comments are recognized during validation and parsing. During formatting, the tool re-serializes the parsed data structure — because most YAML parsers do not attach comments to the data model, comments may not be fully preserved in the formatted output. For validation purposes (checking well-formedness), comments are handled correctly. If preserving comments exactly is critical, copy the formatted version back to your editor and re-add comments manually.

The most frequent errors: (1) Inconsistent indentation — mixing 2-space and 4-space indent, or tabs mixed with spaces. (2) Duplicate keys in the same mapping. (3) Unquoted strings that YAML interprets as special values — "yes", "no", "true", "false", "null", "on", "off" are all interpreted as booleans or null in YAML 1.1 (common in older Kubernetes configs). (4) Colons without spaces in unquoted keys. (5) Missing space after the colon in key: value pairs. (6) Unquoted strings containing YAML special characters (: { } [ ] # &).

YAML is a superset of JSON — valid JSON is also valid YAML. YAML adds human-friendly features JSON lacks: comments, multiline strings, anchors/aliases for reusing values, and less punctuation (no commas between array items, no quotation marks needed for simple string values). JSON has advantages for machine-generated data: it has no indentation-sensitivity, is supported natively by every language, and is unambiguous. For hand-edited configuration files, YAML is generally preferred. For API responses and data storage, JSON is the dominant choice.

No. All formatting and validation runs in your browser using a JavaScript YAML parser. Your config files, which may contain environment variables, credentials, and infrastructure details, never leave your device.