Skip to content
LocalOnly

YAML to JSON Converter

Stable

Parse any YAML config into strict, valid JSON your code can consume.

Everything is processed locally in your browser

About YAML to JSON Converter

Convert YAML into strict, standards-compliant JSON without leaving your browser. This YAML to JSON converter resolves anchors and aliases, honors YAML's native scalar types, and produces JSON that parses cleanly in any language. It's the fastest way to feed a hand-written config or CI file into a program, a JSON schema validator, or an API that only speaks JSON.

Features

  • Fully resolves anchors (&) and aliases (*) into concrete JSON values
  • Maps YAML scalars - numbers, booleans, null and dates - to correct JSON types
  • Supports multi-document YAML and flow-style collections
  • Reports the exact line and column of syntax errors before converting
  • Optional pretty-printed or minified JSON output
  • Handles nested mappings and sequences at any depth without data loss

How to use YAML to JSON Converter

  1. 1

    Paste your YAML

    Paste a YAML document - a config file, manifest, or CI pipeline. Indentation and comments are parsed exactly as YAML intends.

  2. 2

    Convert to JSON

    The parser resolves anchors and types, then serializes the result as JSON. Errors are surfaced with line numbers if the YAML is invalid.

  3. 3

    Copy the JSON

    Grab the pretty or minified JSON output and paste it straight into your code, tests, or an API request body.

Examples

Service config to JSON

YAML mappings and sequences become JSON objects and arrays.

Input

server:
  host: 0.0.0.0
  port: 8080
  tls: true
features:
  - search
  - export

Output

{
  "server": {
    "host": "0.0.0.0",
    "port": 8080,
    "tls": true
  },
  "features": ["search", "export"]
}

How YAML to JSON conversion works

This direction can lose things, because YAML is the larger format

Converting JSON to YAML is lossless, because YAML is a superset. Coming back the other way narrows the data model, and several YAML features have no JSON equivalent at all.

Comments are the first casualty and usually the most significant. Everything after `#` is metadata for humans, and the JSON data model has nowhere to store it. If the YAML file was your documented source of truth, keep it - the JSON is a build artefact, not a replacement.

Anchors and aliases are resolved rather than preserved. An anchored block referenced in five places becomes five full copies in the JSON, since JSON cannot express a reference. The data is correct and the document is larger. Non-string mapping keys are the third gap: YAML permits any type as a key, and JSON requires strings, so a numeric or boolean key has to be coerced.

Where the type surprises come from

Everything ambiguous about YAML's type inference lands in the converted JSON, which makes this conversion a good way to discover problems you did not know your config had. An unquoted `yes` arrives as `true`. An unquoted `1.10` arrives as `1.1`. A value like `0755` may arrive as `493` if the parser reads it as octal.

None of these are conversion bugs - the YAML parser made those decisions, and any tool reading that file would have made the same ones. Seeing the JSON output is simply the first time the interpretation becomes visible, because JSON states types explicitly rather than inferring them.

So if a converted value looks wrong, the fix belongs in the YAML: quote it. That fixes the file for every consumer, not just for this conversion.

Multi-document files and other structural differences

A YAML file can contain several documents separated by `---`, which is extremely common in Kubernetes manifests where one file describes a Deployment, a Service and a ConfigMap. JSON has no equivalent - one file is one value.

The usual resolutions are to convert each document separately, or to wrap them in a JSON array. An array is convenient for programmatic processing but is not what a tool expecting individual resources will accept, so which one is right depends on the consumer.

Empty values are the other thing worth knowing. In YAML, a key with nothing after the colon is null, so `key:` on its own becomes `"key": null` rather than an empty string. That trips people up when a config value was left blank intentionally.

Reference

YAML features and what happens to them

YAML featureIn the JSON outputImpact
# commentsRemovedKeep the YAML as your source of truth
&anchor / *aliasExpanded inlineCorrect data, larger document
--- separatorsNot representableConvert separately or wrap in an array
| block scalarString with \n escapesContent preserved, formatting flattened
> folded scalarString with spacesNewlines become spaces, by definition
Non-string keysCoerced to stringsJSON keys must be strings
key: (empty)nullNot an empty string
yes / notrue / falseQuote in the YAML to keep them strings

Which tool should you use?

These tasks overlap. Here is how to pick the right one for what you are actually doing.

You need to feed a YAML config to something that only reads JSON
This is the standard case, and the conversion is reliable for data.
You want to check how a parser interprets your YAML
Converting is an effective diagnostic. JSON states types explicitly, so inference surprises become visible.
You are converting the other direction
The JSON to YAML tool is lossless, since YAML is the superset.
The YAML holds multiple documents
Split on `---` and convert each separately, unless the consumer is happy with a JSON array.

Use cases

  • Load a hand-edited YAML config into a program that only reads JSON
  • Validate a YAML manifest against a JSON Schema
  • Convert docker-compose.yml into JSON for programmatic inspection
  • Turn CI pipeline YAML into JSON for diffing or auditing
  • Prepare YAML test fixtures as JSON request payloads

Troubleshooting common errors

Comments are missing from the JSON

Why: JSON has no comment syntax, so there is nowhere to put them.

Fix: Treat the YAML as the source of truth and the JSON as generated output. Do not hand-edit the JSON.

"yes" became true

Why: The YAML parser applied YAML 1.1 boolean rules to an unquoted scalar.

Fix: Quote it in the YAML file. Every consumer of that file has been reading it as a boolean, not just this converter.

The output is much larger than the YAML input

Why: Anchors were expanded into full copies at each reference site.

Fix: Expected and unavoidable - JSON cannot express references. The data is equivalent.

Conversion fails on a Kubernetes manifest

Why: The file contains multiple documents separated by `---`, which is not a single JSON value.

Fix: Convert each document on its own, or wrap them in a JSON array if the consumer accepts that.

An empty config value became null instead of ""

Why: In YAML, a key with no value is null by definition.

Fix: Write `key: ""` in the YAML if you specifically want an empty string.

Limitations

What this tool deliberately does not do, so you know when to reach for something else.

  • Comments, anchors and block-scalar formatting cannot survive, since JSON has no equivalents.
  • Multi-document YAML files are not representable as a single JSON value.
  • Non-string mapping keys are coerced to strings.
  • Type inference decisions made by the YAML parser are carried through and cannot be reversed here.
  • Very large files are limited by browser memory, as the whole document is parsed at once.

Frequently asked questions

Learn more

Command Palette

Search for a tool or command