YAML to JSON Converter

What the converter does to your file

YAML is a superset of JSON with a lot of extra spelling. Anchors let one block be reused in five places, merge keys copy defaults into an override, block scalars hold a shell script across ten lines, and a document separator packs six Kubernetes resources into one file. JSON has none of that. Conversion means resolving every shortcut down to plain values, which is exactly what your parser does at deploy time, so the right pane doubles as a preview of what the machine reads.

Anchors and merge keys are flattened, not copied

The sample file defines a defaults block, then pulls it into staging and production with <<: *defaults. Convert it and both environments show the full image name, restart policy and timeout values written out. That expansion is where reused config goes wrong: an override that sits above the merge key silently loses to the anchor in some parsers and wins in others. Seeing the resolved JSON tells you which value survived before a service starts with the wrong timeout.

base: &base
retries: 3
region: eu-west-1
worker:<<: *base
retries: 5

{"base": { "retries": 3, "region": "eu-west-1" },"worker": { "retries": 5, "region": "eu-west-1" }}

Types change on the way across

YAML guesses types from how a value is written. JSON has six of them and no room for the rest. Four conversions account for most surprises in a config file.

Multi-document files

A file with --- separators holds several documents. Kubernetes manifests use this constantly, with a Deployment, a Service and an Ingress stacked in one file. Leave Wrap documents in an array on and the output is a JSON array with one entry per document, which is what most tooling wants. Turn it off and only the first document converts, with a note saying how many were skipped. The document counter under the editors tells you what the parser found, so an accidental separator inside a block scalar shows up as a count you did not expect.

Reading an error

A failure reports the line and column from the parser along with the reason. Three causes cover almost everything in real files. A tab character used for indentation, which YAML rejects outright. A duplicate key in the same mapping, which the parser refuses rather than silently picking one. And a value starting with a character that opens a structure, such as an unquoted * or {, which reads as an alias or a flow mapping instead of text.

The line number points at where parsing stopped, not always where the mistake is. An unclosed quote on line 12 usually reports somewhere further down, once the parser runs out of file. Check the lines above the reported one when the flagged line looks fine. For a file you have not written yourself, the YAML validator walks the whole document and lists every problem instead of stopping at the first.

Where this tool stops

• Custom tags are rejected. A file using !Ref, !GetAtt or any other application tag fails to parse. CloudFormation templates written in YAML fall into this group, and they need a converter that knows those tags.
• No schema check. Valid JSON says nothing about whether the shape is right for your API. Generate a schema with the YAML to JSON Schema tool when the structure needs enforcing.
• Key order follows the source unless you sort. JSON objects have no defined order, so a diff between two converted files can show noise from ordering alone. Sorting keys on both sides removes that.
• Everything runs on the main thread. Files up to a few hundred kilobytes convert instantly. A multi-megabyte manifest bundle makes typing feel sticky, and at that size a script using the same js-yaml library is the better call.
• Nothing is uploaded. Parsing and formatting happen in this tab after the page loads, so a config file holding internal hostnames or a token never reaches a server.