YAML to JSON Converter
Indentation to brackets. For when you need to be explicit.
What this does
Paste YAML, get JSON. Comments are dropped (JSON doesn't support them). Anchors and aliases are resolved into actual values, and << merge keys are applied.
Here's a Compose-style file with a shared block of defaults:
defaults: &defaults
restart: always
country: NO
services:
web:
<<: *defaults
port: 8080
mode: 0755
version: 1.10
released: 2024-01-01The JSON:
{
"defaults": {
"restart": "always",
"country": "NO"
},
"services": {
"web": {
"restart": "always",
"country": "NO",
"port": 8080,
"mode": 755,
"version": 1.1,
"released": "2024-01-01"
}
}
}The merge key copied restart and country into web. NO stayed a string. Now look at mode and version: 0755 came out as 755 and 1.10 as 1.1. Unquoted, they're numbers, and numbers don't keep leading or trailing zeros. If they're meant to be strings, quote them in the YAML.
Common use cases
Checking what a YAML file actually means. JSON makes every type explicit, so a version number that quietly became a float shows up right away.
Feeding YAML configs into JSON-only tools: jq, a JSON Schema validator, an API that wants a JSON body.
Debugging Kubernetes manifests and CI files by making the nesting explicit with brackets. A key that landed one level too deep is hard to miss once it's wrapped in braces.
Things to know
YAML allows things JSON doesn't: comments, anchors, multi-line strings, unquoted keys. All of these are handled during conversion. YAML's indentation sensitivity is its biggest gotcha. When the parser gives up, the error names the line and column, and tabs used for indentation are rejected outright.
Dates come through as the strings you wrote, so 2024-01-01 stays "2024-01-01" instead of turning into a timestamp. A file with several documents split by --- becomes a JSON array, one entry per document. Huge integers keep every digit. Custom tags like CloudFormation's !Ref don't break anything: the tag is dropped and the value comes through untouched.
Parsing follows YAML 1.2, the current spec. yes, no, on and off stay strings, and 0755 is decimal. PyYAML still follows 1.1 and would read the same values as booleans and the octal number 493. This JSON shows what a 1.2 parser sees, so check your target if it's Python.
With merge keys, explicit keys always beat merged ones, wherever the << line sits. Merge a list like [*a, *b] and the first one listed wins. .inf and .nan become null, since JSON has no way to write them.
Privacy
Parsed and converted in your browser. Your YAML files stay local, along with whatever passwords someone committed to them.
Questions
What happens with duplicate keys?
The conversion stops with an error pointing at the second one. The YAML spec says keys in a mapping must be unique, and some parsers quietly keep the last value instead. This one makes you pick.
Does it work with CloudFormation templates?
For reading, yes. Short-form tags like !Ref, !GetAtt and !Sub are dropped and their values come through as plain data, so !Ref MyBucket becomes "MyBucket" and !GetAtt MyBucket.Arn becomes "MyBucket.Arn". Don't deploy the result. CloudFormation's JSON format needs {"Ref": ...} objects to know what's a reference.
Is it safe to paste YAML from an untrusted source?
Yes. Parsing builds plain data only: no custom types, no code execution, which is the attack PyYAML's unsafe loader is famous for. Alias bombs hit the expansion cap and fail with an error before they can eat your tab.
What happens to keys that aren't strings?
They become strings, since JSON keys can't be anything else. 1: a turns into "1": "a" and true: b into "true": "b". A list used as a key ends up as the text "[ x, y ]", which is about as useful as it sounds.