Simple key-value YAML, converted to matching JSON types
'name: veomark', 'version: 1.0', and 'live: true' convert to {"name": "veomark", "version": 1, "live": true} -- each YAML scalar type maps to its corresponding JSON type: a string stays a string, a boolean stays a boolean, and a number is parsed as a number.
Notice 'version: 1.0' becomes the JSON number 1 rather than the string '1.0' -- this is a real, easy-to-miss gotcha: YAML's unquoted 1.0 is interpreted as a numeric value, and standard JSON number formatting drops the trailing .0 for a value that's mathematically a whole number, which can silently change a version string's format if you expected '1.0' to be preserved literally as text.
If preserving '1.0' as literal text (rather than the number 1) is important -- like a semantic version string -- wrapping the YAML value in quotes ('1.0' or "1.0") would force it to convert as a JSON string instead of being parsed as a number.
Why this only handles flat, simple YAML
Flat YAML only. Nested maps, lists, and multiline scalars are ignored. YAML's real power (and complexity) comes from nested mappings, lists, anchors/references, and multiline string scalars -- none of which this simplified converter parses. It's built for flat, single-level key-value YAML, which covers many simple config snippets but not YAML's full feature set.
A YAML file with indented nested structures (a map or list as a value) would not convert correctly here, since this tool doesn't track indentation-based nesting the way a full YAML parser does.
For anything beyond simple flat key-value pairs -- real application config files, Kubernetes manifests, GitHub Actions workflows -- a full-featured YAML parser or linter is the appropriate tool rather than this simplified flat converter.
Related YAML and config-format tools
For validating more complex, real-world YAML structure and syntax (rather than converting it), the YAML Linter is the appropriate next step.
To go the other direction -- JSON back into YAML -- the JSON to YAML Converter handles that.
Frequently Asked Questions (FAQ)
Why does 'version: 1.0' convert to the number 1 instead of '1.0'?
An unquoted 1.0 in YAML is interpreted as a numeric value, and standard JSON number formatting represents a whole-number value without a trailing .0. If you need '1.0' preserved as literal text, quote it in the YAML source ('1.0' or "1.0") so it converts as a JSON string instead.
Does this handle nested YAML structures, like a map or list as a value?
No. Flat YAML only. Nested maps, lists, and multiline scalars are ignored. This converter is built for simple, single-level key-value pairs. Indented nested mappings or lists as values require a full YAML parser, which this simplified tool doesn't implement.
Does this handle multiline string values (using | or > YAML syntax)?
No. Flat YAML only. Nested maps, lists, and multiline scalars are ignored. YAML's multiline scalar block syntax isn't parsed by this simplified flat converter.
How does this converter decide something is a boolean versus a string?
Unquoted values matching YAML's boolean keywords (like true or false) convert to JSON booleans. Quoting a value in the YAML source (like "true") would force it to be treated as a literal string instead, since quotes signal explicit string type in YAML.
Is this suitable for converting a real application config file?
Only for very simple, flat config snippets. Real-world config files (Kubernetes manifests, CI/CD workflows, application settings) typically use nested structures and lists that this flat-only converter doesn't support -- use a full YAML parser for those.
