Your Kubernetes manifest is YAML. Your API wants JSON. Here is the conversion, done right

Every developer who has touched Kubernetes, Docker Compose, or a GitHub Actions workflow has hit the same small wall. The config lives in YAML. The tool that needs to consume it, validate it, or pipe it through jq only speaks JSON. So you convert it. And the conversion is where quiet bugs are born.

YAML is not JSON with nicer formatting

It looks like it. Both describe nested maps and lists. But YAML has opinions JSON does not. A bare yes is a boolean in YAML 1.1 and a string in YAML 1.2. on and off have the same split personality. A timestamp like 2026-11-08 can silently become a date object in one parser and stay a string in another. Anchors (&defaults) and aliases (*defaults) let one block appear in five places, and merge keys (<<) fold shared config into a service definition. None of that exists in JSON, so a converter has to decide what each of those becomes, and a careless one decides wrong without telling you.

The classic failure looks like this. A Docker Compose file defines a shared logging block once with an anchor, then reuses it in three services. Someone pastes it into a converter that drops anchors instead of expanding them. The JSON comes out clean, valid, and wrong: three services with no logging config at all. Nothing errors. The deploy goes out, and the missing logs are discovered at 2am, during an incident, when logs are the one thing you need.

What a good conversion actually does

First, it expands anchors and merge keys into full copies, so every place that referenced a block gets the complete block. Second, it tells you which YAML version its typing follows, because enabled: yes becoming true or "yes" changes what your application does. Third, it handles multi-document files. A Kubernetes manifest is often three documents separated by --- in one file, and the honest JSON for that is an array with one entry per document, not a silent merge that drops two of them. Fourth, it reports errors with a line and column, because "invalid YAML" without a location is not an error message, it is a shrug.

The reverse direction matters just as much. JSON to YAML should produce readable block style, not a wall of flow syntax, because the YAML you get back is usually going into a file a human will edit next.

The privacy part nobody thinks about until it is too late

YAML files are where secrets hide in plain sight. A Compose file holds registry credentials. A Helm values file holds tuned internal hostnames. A GitHub Actions workflow embeds environment names and deployment logic. Pasting any of that into a server-side converter sends your infrastructure's address book to a stranger's server. A converter that runs entirely in your browser never uploads anything, and that is not a marketing line, it is the only safe way to handle config files.

I built a free converter that does all of this in the browser: YAML to JSON and back, multi-document files become a JSON array, anchors expand properly, errors come with exact line numbers, and nothing ever leaves your device. It is at YAML to JSON Converter. Try it with a real Compose file, then check the JSON against what you expected, especially any anchors. If the output surprises you, the surprise was in your YAML all along, and now you know before production tells you.