YAML Formatter
YAML Formatter parses your YAML and writes it back with clean two-space indentation and block-style collections, plus a compact mode for dense files. Handy for Kubernetes, CI and Compose configuration. Note that comments are removed and numbers such as 1.10 become 1.1 unless quoted.
使用方法 YAML Formatter
出力
コンテンツを読む
What the formatter does
Paste YAML and it is parsed, then written back out with consistent indentation: two spaces per level, one key per line, block-style collections instead of inline brackets. A second mode produces a more compact rendering that keeps nested structures on the same line where the format allows it.
Both modes run on the server. The page gives you a manual tab and a fetch-from-URL tab, character counters for input and output, a copy button, and a download named beautify-output.yml.
The important part: it rewrites, it does not just re-indent
Most people expect a formatter to move spaces around. This one cannot work that way, because the YAML is first parsed into data and then serialised from that data. Anything the parse cannot represent is lost, and anything the serialiser decides differently is changed. That single fact explains every surprise below.
If you need the original comments, alignment and quoting preserved exactly, a text editor's reindent function is the right tool. If you want a clean, canonical document that a machine will read, this is the right tool.
What changes, with examples
| Input feature | Result after formatting |
|---|---|
| Comments | Removed entirely |
| Flow lists and maps | Expanded to block style with indentation |
| Quote style | Re-chosen by the serialiser, often single quotes |
| Anchors and merge keys | Resolved; the shared values are copied into each place |
| Key order | Preserved as written |
| Unquoted numbers | Stored as numbers, which can change how they print |
| Empty values | Written as null |
| Long lines | Wrapped at the serialiser's width |
| Indentation of nested maps | Two spaces per level |
The quote change is cosmetic but visible: a value typed as "true" comes back as 'true'. The serialiser also quotes keys that look like booleans in the older YAML specification, so a key named y can appear as 'y'. Both forms mean the same thing to a parser.
The number trap
YAML does not know that a version string is a string. If you write:
version: 1.10
the value is parsed as the number 1.1 and printed back as:
version: 1.1
The trailing zero disappears because it was never part of the value — only part of the notation. This is correct YAML behaviour and a genuine hazard for dependency versions, schema versions, API versions and anything else where the zeros matter. Quote such values before formatting:
version: "1.10"
The same applies to values like 007, which is read as an octal integer in some YAML versions, and to identifiers made only of digits. Quoting is always safe for these; the formatter will preserve the quotes and the exact text.
What the parser rejects
- Multiple documents in one stream. A file separated by
---lines is not accepted; split it first. - Tabs used for indentation. YAML forbids them. Replace tabs with spaces.
- Unquoted colons inside values. A line like
text: hello: worldis ambiguous and fails; quote the value. - Broken nesting or missing indentation. The parser stops at the first structural error.
The error message is always the same: invalid YAML input. There is no line number and no hint about where the problem is. For a long document, bisect by pasting the first half, then the second, until the failing block is isolated; that is usually faster than reading every line.
An empty input is a special case: it parses to nothing and outputs the word null. That is valid YAML representing an empty document, but it is not what most people expect from an empty box.
The compact mode
The second mode is labelled minify, but YAML cannot be flattened onto one line the way JSON can. What it does is allow deeper inline nesting, so lists and small maps collapse onto a single line while the overall document keeps its line structure. The result remains valid YAML, just denser. It is useful for eyeballing a large configuration and useless for saving meaningful bytes once a compressor is involved.
Using the page
- Paste your YAML into the manual tab, or use the URL tab to fetch a raw file.
- Make sure the language selector reads YAML and choose Beautify or Minify.
- Press the convert button. The output appears in the right-hand panel.
- Compare the input and output counters in the footer; a large drop usually means comments and inline collections were rewritten.
- Copy the result or download it as
beautify-output.yml. - Run your own linter or a dry-run command before committing. Formatting is not validation.
Where it earns its place
Kubernetes manifests, GitHub Actions workflows, Docker Compose files, Ansible playbooks and CI configuration are all YAML, and all of them are edited by hand under time pressure. A pass through the formatter reveals indentation mistakes that the eye misses, and standardises a file that three people have edited in three styles.
It is also handy for reading YAML exported from a tool that writes everything on one line, and for turning a dense inline document into something reviewable in a pull request. Because key order is preserved, the diff shows structural changes rather than a reshuffle.
Safety before you commit
Because comments disappear and anchors are resolved, never overwrite the only copy of a commented configuration. Keep the original in version control, paste a copy, and diff the result before accepting it. If the file relies on anchors to avoid repetition, decide whether the duplication matters; it usually does not for behaviour, but it can for maintenance.
Quoted values that look like numbers should also be double-checked in the output. And if the document contains credentials, tokens or connection strings, remember that it is being uploaded.
Privacy
Parsing happens on the server, so the text leaves your browser. Do not paste production secrets, private keys or customer data. The page keeps no history, but the request itself carries the content, which is enough reason to strip sensitive values before formatting.
Limits
200,000 characters per request. One document at a time, no schema validation, no line-level error messages, no comment preservation, no anchor preservation, no conversion to JSON or XML and no diff view. The serialiser chooses its own quoting and line width, so the output is canonical rather than identical to your input. There is no option to sort keys, set indent width, or disable wrapping.
Common mistakes
- Expecting a pure reindent. The document is rebuilt from parsed data.
- Losing comments. They are not part of the data model and cannot survive.
- Formatting a version number unquoted. The trailing zero vanishes.
- Pasting a multi-document file. Split on the separator first.
- Using tabs. They are invalid indentation in YAML.
- Treating a clean output as proof of correctness. It parses, but it may not match your schema.
Frequently Asked Questions
よくある質問
コメント (0)
発生した問題について詳しくご説明ください。調査を行い、ツールの改善に役立てたいと思います。