YAML ↔ JSON Converter

How to Convert YAML to JSON

YAML is a superset of JSON, so most valid YAML converts cleanly to JSON. Paste your YAML into the left panel and click Convert (or just start typing — conversion happens automatically). The right panel shows formatted, indented JSON. Arrays, nested objects, and quoted strings are all handled correctly.

Everything runs in your browser. Your YAML is never uploaded, logged, or sent to a server, which matters because config files routinely contain hostnames, internal service names, and occasionally secrets that should never touch a third party's logs. You can confirm this by opening your browser's network tab and converting — there are no outbound requests.

server:
  host: api.example.com
  port: 8080
  tags:
    - production
    - eu-west
  tls: true

{
  "server": {
    "host": "api.example.com",
    "port": 8080,
    "tags": [
      "production",
      "eu-west"
    ],
    "tls": true
  }
}

How to Convert JSON to YAML

Switch to "JSON → YAML" mode using the toggle above. Paste your JSON in the left panel and the converter outputs clean YAML. JSON always produces valid YAML since JSON is a valid YAML subset. Use "Use as Input" to chain multiple conversions.

This direction is lossless in the strict sense — every JSON value has a YAML representation — but it is not reversible in the sense people usually expect. Comments in your original YAML are gone forever once you convert to JSON, because JSON has nowhere to put them. If you are round-tripping a config file through JSON to run a transformation, expect to reapply comments by hand. Anchors, aliases, and custom tags are likewise flattened.

YAML vs JSON: Key Differences

YAML Features That Have No JSON Equivalent

Four YAML constructs simply cannot survive the trip to JSON. Knowing which ones you are using tells you in advance what the conversion will cost.

Comments

Anything after an unquoted # is a comment. JSON has no comment syntax at all, so comments are silently dropped. This is the single most common surprise when teams convert a hand-maintained Kubernetes manifest to JSON and then convert it back.

Anchors and aliases

YAML lets you define a node once with &name and reuse it with *name, optionally merging with <<. The converter resolves these — it expands the reference and inlines the value — so the JSON is correct but the deduplication is lost.

defaults: &defaults
  retries: 3
  timeout: 30

staging:
  <<: *defaults
  host: staging.example.com

Converts to JSON in which staging contains a full literal copy of retries and timeout. Convert back to YAML and you get the expanded form, not the anchors.

Multiple documents in one file

YAML files can hold several documents separated by ---, which is how a single Kubernetes manifest declares a Deployment and a Service together. JSON has exactly one root value, so a multi-document YAML file has no direct JSON equivalent — this converter reports expected a single document in the stream rather than guessing. Convert each document separately, or wrap them in a JSON array yourself.

Native dates and non-string keys

YAML parses an unquoted 2024-03-15 into a real date type and permits numbers, booleans, or even sequences as mapping keys. JSON has neither. The date is serialised as a full ISO 8601 instant — "2024-03-15T00:00:00.000Z", with a midnight UTC time you never wrote — and non-string keys are coerced to strings. Quote the value if you want the original text preserved exactly.

Five YAML Gotchas That Break Conversions

Most "the converter is wrong" reports are actually YAML behaving exactly as specified in ways that surprise people. These are the five worth memorising.

How YAML Values Map to JSON Types

This is the conversion this tool actually performs — every row below is the literal output you get by pasting the input on the left. It follows the YAML 1.2 core schema. When output surprises you, check the input against this first.

Where YAML to JSON Conversion Actually Comes Up

Three situations account for most conversions.

Feeding config to a tool that only speaks JSON. Kubernetes manifests, Docker Compose files, and GitHub Actions workflows are authored in YAML, but plenty of validators, policy engines, and diffing tools accept JSON only. Converting is the bridge. Since kubectl accepts both formats natively, the conversion is usually for the surrounding tooling rather than the cluster.

Inspecting an API response as config. APIs return JSON; when you need to commit part of that response into a config file, YAML is far easier to review in a pull request. Converting JSON to YAML before committing produces a diff a human can actually read.

Debugging indentation. When a YAML file is not doing what you expect, converting it to JSON shows you the structure the parser actually built. If a key landed one level deeper than intended, the JSON braces make it obvious immediately. This is the fastest way to diagnose a misindented CI pipeline — and if that pipeline runs on a schedule, our cron expression generator will tell you exactly when the schedule fires.

Converting Between Other Formats

YAML and JSON are two points in a wider set of data formats, and the same document often has to reach all of them. Once your YAML is JSON, three neighbouring conversions cover almost everything else.

Checking and reshaping the JSON itself. Our JSON formatter and validator beautifies, minifies, and sorts keys, and reports syntax errors by line and column. Sorting keys on both sides before a diff is the fastest way to tell a real config change from a reordered export.

Getting the data into a spreadsheet. When a config or an API export has to reach someone who works in Excel or Sheets, JSON ↔ CSV flattens nested objects into dot-notation columns and parses them back into nested JSON afterwards.

Talking to systems that predate JSON. SOAP APIs, RSS feeds, Maven builds, and .NET configuration are all XML. XML ↔ JSON handles attributes, CDATA, and repeated elements, and is usually the first step when migrating legacy configuration onto a YAML-based toolchain.

Frequently Asked Questions