YAML ⇄ JSON: what it does and how to use it

YAML and JSON describe the same data model - objects, arrays, strings, numbers, booleans, null - with different syntax. JSON uses explicit braces and brackets, which makes it unambiguous and verbose. YAML uses indentation, which makes it readable and fragile. In fact every valid JSON document is already valid YAML, since YAML 1.2 was defined as a superset, which is why converting JSON to YAML always works cleanly. The other direction has one genuine loss: comments. YAML supports them and JSON has no comment syntax at all, so every explanatory note in a config file disappears on conversion - and configuration files are exactly where comments carry the most value. There are also YAML features with no JSON equivalent, such as anchors and references for reusing a block. Both directions run in your browser, so config files containing credentials are never transmitted.

You should not have to open an IDE to format a snippet from Slack, tidy a JSON blob, or check a hash. Paste it here, copy the result, move on.

YAML ⇄ JSON is a good fit when converting a JSON API response into YAML for a config file.

The useful part

YAML ⇄ JSON is built around a few practical wins, not a long feature list:

• Handles both directions, covering the config-to-API and API-to-config cases.
• Reports syntax errors with position rather than failing silently.
• Runs in your browser - config files routinely contain secrets and connection strings.
• No size limit imposed by a server.
• No account required.

Do this, in order

1. Choose the direction. YAML to JSON, or JSON to YAML. Each has different consequences.
2. Paste your input. A config file, an API payload, or a manifest.
3. Convert. Syntax errors are reported with their position, which for YAML is usually an indentation problem.
4. Check what was lost. Converting YAML to JSON strips comments and resolves anchors. Keep the YAML if those matter.

Who it is for

• Converting a JSON API response into YAML for a config file.
• Turning a Kubernetes or Docker Compose manifest into JSON for a tool that requires it.
• Feeding YAML configuration into code that only parses JSON.
• Comparing two config files by converting both to one format first.
• Checking that a YAML file parses to the structure you expect.

If you want a clean result

• Keep the YAML original when converting to JSON. Comments are lost permanently and cannot be recovered from the JSON.
• Every JSON document is already valid YAML, so that direction never fails on structure.
• Quote version numbers and any value that could read as a boolean before converting - YAML turns 1.10 into 1.1 and no into false.
• YAML anchors and references are resolved into repeated data on conversion, which makes the JSON larger and loses the reuse.
• If you only need to tidy YAML rather than change format, the YAML Formatter validates without converting.

Common mix-ups

• Converting a commented config to JSON and discarding the YAML, losing every explanatory note.
• Expecting a YAML to JSON to YAML round trip to return the original file - comments and anchors do not survive.
• Leaving version numbers unquoted so 1.10 becomes 1.1 in the converted output.
• Assuming JSON is invalid YAML. It is not - the superset relationship means JSON parses as YAML directly.
• Pasting production configuration into a converter that uploads it. This one does not.

Private by default

YAML ⇄ JSON runs in your browser. The file or text you paste stays on your device. There is no account, and nothing is stored on a ToolBox server for this job.

Related tools worth opening next

If this is one step in a longer job, these usually come after it:

• YAML Formatter - Format and validate YAML documents
• TOML ⇄ JSON - Convert between TOML and JSON formats
• JSON ⇄ XML - Convert between JSON and XML formats

Before you ask

Will converting YAML to JSON and back preserve everything exactly?

For standard data structures, yes - both formats represent the same underlying data (objects, arrays, strings, numbers), so a round trip generally preserves the content, though YAML-specific features like comments won't survive since JSON has no concept of comments.

Does it handle YAML anchors and references?

Basic anchors/aliases (YAML's way of reusing a block of data) are typically resolved into their expanded form when converting to JSON, since JSON has no equivalent shorthand.

Which format should I use for my config file?

Whatever the tool expects - Kubernetes, Docker Compose and most CI systems use YAML, while APIs almost universally use JSON. Where you have a genuine choice, YAML wins for anything a human edits, because it supports comments.

Why do my comments disappear converting YAML to JSON?

Because JSON has no comment syntax at all - there is nowhere for them to go. This is the main reason to keep the YAML original rather than treating the JSON as a replacement, since config comments usually explain why a value is what it is.

Is JSON valid YAML?

Yes. YAML 1.2 is defined as a superset of JSON, so any JSON document parses as YAML unchanged. That is why converting JSON to YAML always succeeds structurally, while the reverse can lose YAML-only features.

Is my configuration uploaded anywhere?

No. Conversion runs in your browser, which matters because config files routinely contain connection strings, API keys and other secrets.

Open the YAML ⇄ JSON when you are ready. It is free, and you do not need an account.