YAML to JSON Converter

The two formats describe the same data

JSON and YAML both encode the same small set of types: mappings, sequences, strings, numbers, booleans and null. YAML is in fact a superset of JSON, which means any valid JSON document is already valid YAML. Conversion in that direction is therefore lossless and uninteresting. Going the other way is where the judgement calls live, because YAML has features JSON simply cannot represent.

What does not survive a round trip

• Comments. JSON has none, so YAML comments are dropped on conversion. This is the single most common surprise, since configuration files are usually heavily commented.
• Anchors and aliases. YAML can define a node once and reference it elsewhere. JSON has no reference mechanism, so these have to be expanded.
• Multiple documents. One YAML file can hold several documents separated by ---, which is standard in Kubernetes manifests. JSON holds exactly one value.
• Explicit type tags and non-string keys have no JSON equivalent.

The Norway problem, and why quoting matters

YAML infers types from unquoted scalars, and historically that inference was aggressive enough to be famous. Under the older YAML 1.1 rules, the unquoted values yes, no, on and off were booleans, which meant the country code for Norway, NO, parsed as false. YAML 1.2 narrowed booleans to true and false, but many parsers still implement the older behaviour.

This converter follows the 1.2 rules: only true and false, in lower case or capitalised, become booleans. Everything else that is not clearly a number stays a string. The lesson generalises: if a scalar's type matters, quote it. Version numbers are the classic casualty, since 1.10 is a number that will lose its trailing zero and become 1.1, while "1.10" stays intact.

Indentation rules

YAML nesting is expressed entirely through indentation, with two hard rules: indentation must use spaces, never tabs, and sibling keys must align exactly. Most YAML errors in practice are one of those two. A tab character is invisible in most editors and produces a parse error that points at a line which looks perfectly correct.

Sequence items under a key may be indented at the same level as the key or one level deeper; both are legal and both are common, which is a frequent source of confusion when reading other people's files.

Why converting locally matters here

YAML is overwhelmingly a configuration format, and configuration files carry connection strings, API keys and infrastructure detail. Pasting a Kubernetes manifest or a CI pipeline definition into a hosted converter discloses it. Everything here runs in your browser, so the file never leaves your machine.

Questions

Are comments preserved when converting to JSON?

No, and they cannot be. JSON has no comment syntax, so comments are dropped. If you need to keep them, keep the YAML file as the source of truth and generate JSON from it as a build step.

Why did my version number 1.10 become 1.1?

Unquoted, it is parsed as a number, and the trailing zero is not significant in a number. Quote it as "1.10" to keep it as a string. The same applies to any value where the exact text matters.

Does it support multi-document YAML files?

Document separators are skipped rather than producing separate outputs, because JSON holds a single value. For multi-document files such as Kubernetes manifests, convert one document at a time.

Are yes and no treated as booleans?

No. This converter follows YAML 1.2, where only true and false are booleans. Under older YAML 1.1 rules yes, no, on and off were also booleans, which famously turned Norway's country code NO into false.

Can I convert JSON back to YAML?

Yes, press To YAML. Strings that could be misread as another type, such as true or a bare number, are quoted automatically so the result parses back to the same values.