YAML to JSON Converter
For Kubernetes manifests, CI configs and Ansible playbooks you need in JSON form.
The subset that covers real config files
The YAML specification is enormous, and almost none of it appears in ordinary configuration. What actually shows up — and what this converter handles — is a small, well-defined core:
- Block mappings and block sequences with space indentation.
- Plain scalars, single-quoted scalars and double-quoted scalars with escapes.
- Block scalars for multi-line strings:
|keeps line breaks,>folds them into spaces. - The document start marker
---, and#comments, including trailing comments after a value. - Inline flow collections
[a, b]and{k: v}, which are JSON-compatible by design.
Where a small parser meets its limits
| Feature | Status | What to do instead |
|---|---|---|
Block scalars | and > | Supported | — |
| Comments | Stripped | JSON cannot carry comments |
Anchors and aliases &/* | Not expanded | Resolve them before converting, or use a full parser |
Merge keys << | Not merged | Expand manually |
Custom tags !!str | Not applied | Remove them or use a schema-aware parser |
| Multiple documents in one file | First document | Split on --- first |
Comments disappear, and that is the point
JSON has no comment syntax, so converting YAML to JSON always discards them. That is usually harmless for a machine that just needs the data — but it makes the conversion a one-way operation. If the file is edited by people, keep the YAML as the source of truth and convert in the other direction for the tools that require JSON. Round-tripping JSON → YAML → JSON preserves values; YAML → JSON → YAML does not preserve comments.
Why the colon rules bite
A colon is a key separator only when followed by a space or end of line. That single rule explains two common failures: a URL like http://example.com is a fine plain scalar because the colon is followed by a slash, while a value like time: 12:30 breaks because 12:30 looks like it begins a nested mapping. Quote the value and the ambiguity disappears. The same rule applies to a leading -, which becomes a sequence indicator unless the value is quoted.
Parsing untrusted YAML
If the YAML arrives from an untrusted source, do not parse it with a full-featured loader. Aliases expand, and nested aliases expand exponentially — a file of a few kilobytes can be made to consume gigabytes of memory. Any production pipeline accepting untrusted YAML should disable alias expansion and cap document size, and a strict subset parser like this one sidesteps the problem entirely.
How to use it
- Paste the YAML document.
- Convert and inspect the resulting JSON structure.
- Check the value types — a
nomay have becomefalsedepending on how it was quoted in the source. - Validate against your schema before use.
Worth knowing
- A colon separates a key only when followed by whitespace or end of line.
- Tabs are never valid indentation in YAML.
|preserves line breaks in a block scalar;>folds them into spaces.- Alias expansion can be used to exhaust memory from a tiny document.
Limitations
- Anchors, aliases, merge keys and custom tags are not expanded.
- Only the first document in a multi-document file is converted.
- Comments are discarded, so this conversion is not reversible.
- YAML 1.1 implicit typing may differ from what your production parser does.
Frequently asked questions
Why did `no` become `false`?
no as a boolean. It is the Norway problem. Quote such values in the source — "no" — to keep them as strings.Can I keep the comments?
How do I convert a Kubernetes manifest?
---, convert them one at a time.