YAML to JSON

Tips for Trustworthy YAML to JSON Conversions

• Leave YAML 1.1 Legacy Booleans off unless you know you need it — the default already matches how modern tools like Kubernetes and recent Docker Compose versions actually read your file.
• Watch for the multi-document hint banner. If your file has more than one ----separated section, the output becomes an array automatically — that's expected, not a bug.
• Trust a duplicate-key error over guessing. It almost always means a real copy-paste mistake in the source file, not a parser being overly strict.
• Check a converted config with anchors and merge keys carefully the first time — confirm the merged result has the values you expect before using it, especially with multi-alias merges.

Features

Why a Real YAML Parser Matters Here

YAML looks simple — indentation instead of braces, dashes instead of brackets — right up until you hit a multi-line block scalar with a specific chomping indicator, a flow collection nested three levels deep, or an anchor referenced from somewhere unexpected. A converter built by pattern-matching common cases will handle the config file you tested it with and quietly misparse the one a colleague sends you next week. This tool runs js-yaml, a mature, specification-tracking parser used throughout the JavaScript ecosystem, entirely inside your browser tab — so what comes out the other side is what a real YAML implementation actually resolves, not a best guess.

That distinction matters most exactly when you can least afford to be wrong: converting a production Kubernetes manifest, a CI pipeline definition, or an infrastructure config where a silently misparsed value doesn't throw an error — it just deploys the wrong thing.

Multi-Document YAML: The --- Separator

A single YAML file can hold more than one independent document, each one starting with its own --- line — Kubernetes manifests routinely bundle a Deployment, a Service, and a ConfigMap in one file this way. Feed that to a naive converter expecting one JSON object and it either errors out or silently keeps only the first document. This tool parses every document in the stream and represents the result faithfully: one document converts to one JSON value, more than one becomes a JSON array with an entry per document, and a banner tells you exactly how many were found so there's no guessing about whether something got dropped.

Inspecting the Output

Once the JSON is on screen, the raw text box is rarely the easiest way to explore it — especially with a deeply nested Kubernetes resource or a multi-document array. Paste the result into the JSON Formatter for a clickable tree view with JSONPath lookups, which makes it far faster to confirm a merge key resolved the way you expected than scrolling through indented text.

Merge Keys: << Actually Merges, Not Just Sits There

YAML's merge key lets one mapping inherit another's keys — service: {<<: *defaults, retries: 5} pulls in everything from the defaults anchor, with retries: 5 explicitly overriding whatever the anchor set. It's a common pattern in Docker Compose and CI configs for avoiding repetition. Handled incorrectly, a parser leaves a literal property named "<<" holding the anchor's data instead of actually merging it in — technically parsed, semantically wrong. This converter resolves merge keys properly, including the multi-alias form (<<: [*a, *b]), so the JSON you get matches what the config was actually designed to mean.

Duplicate Keys: An Error by Default, Not a Silent Overwrite

The YAML specification requires every key within a mapping to be unique, which means a duplicate almost always signals an accidental copy-paste rather than an intentional structure — someone duplicated a block while editing and forgot to rename one field. This converter treats that as an error by default, pointing at the exact line and column rather than silently keeping whichever value happened to come last, the way a more permissive, JSON-object-style parser would. Allow Duplicate Keys is there for the rarer case where that permissive behavior is genuinely what you need, but it's an opt-in rather than the default specifically because a silent duplicate is far more often a bug worth catching than a real intent.

Avoiding the Norway Problem on the Way In

The flip side of our JSON to YAML converter's quoting logic shows up here too. Under YAML 1.1, unquoted yes, no, on, and off resolve as booleans — the famous case being Norway's ISO country code "NO" silently becoming false. This tool defaults to modern YAML 1.2 behavior, where only true and false are booleans and everything else stays exactly the text it was written as. If you're working with a file you know was written for a YAML 1.1 tool that relies on the old behavior, the Legacy Booleans switch is there — but the safe default means you won't get surprised by it when you're not expecting to.

Who Actually Converts YAML to JSON

Backend developers reading a Kubernetes or Docker Compose file into a script that expects JSON. DevOps engineers auditing a CI/CD pipeline definition by inspecting its actual resolved structure, merge keys and all. Frontend developers consuming a YAML-based config or content file in a JavaScript application that only speaks JSON natively, sometimes alongside an XML to JSON step for the same app. Anyone debugging why a YAML-driven tool is behaving unexpectedly, who wants to see exactly what the parser resolved rather than what the file appears to say.

From Kubernetes Manifests to CI Config: Real Scenarios

Auditing a Kubernetes manifest before applying it. Paste a multi-document manifest, convert, and inspect the resolved JSON for each resource — including any << merge keys pulling in shared defaults — before it goes anywhere near a cluster.

Feeding a YAML config into a JavaScript build tool. Convert once at build time (or interactively here while developing), and the rest of the pipeline works with plain JSON, no YAML parsing dependency required downstream.

Comparing two versions of a CI pipeline file. Convert both to JSON with Sort Keys on, then compare them in the Text Diff Checker — the resolved structure, not just the raw YAML text, makes it obvious whether a merge key change actually altered the effective configuration.

Everything Runs in Your Browser

Config files are exactly where credentials, internal hostnames, and infrastructure details tend to live. Parsing happens through js-yaml running as plain JavaScript in your browser tab — nothing you paste or upload is transmitted to a server, and the tool keeps working offline once the page has loaded.

What This Tool Won't Do

It converts YAML to JSON faithfully — it doesn't validate the result against a Kubernetes schema, a JSON Schema, or any application-specific contract. Valid YAML that resolves to the wrong shape for your application will still convert cleanly; catching that requires a schema validator, not a format converter. And because JSON has no native way to represent a YAML alias as a reference, every alias becomes an independent copy of the data in the output — if your workflow specifically depends on shared references surviving the conversion, JSON simply isn't able to express that. Going the other way — turning JSON back into readable YAML — is a different set of tradeoffs entirely, covered by the JSON to YAML converter.

Frequently Asked Questions