🔁 YAML ↔ JSON Converter

Convert between YAML and JSON instantly. Multi-document, sort keys, custom indent — all in your browser.

Paste input to convert
INPUT · YAML
OUTPUT · JSON
{ }

JSON output will appear here

About this YAML ↔ JSON Converter

YAML (YAML Ain't Markup Language) and JSON are the two most common formats for configuration files, API responses, and infrastructure definitions. Kubernetes manifests, GitHub Actions workflows, Helm charts, Spring Boot application.yml, and Ansible playbooks all use YAML. REST APIs, microservices, and most databases use JSON. This tool lets you flip between the two instantly — no server, no sign-in, no data ever leaving your browser.

The converter handles real-world edge cases: multi-document YAML (files with multiple ---separators), nested structures of any depth, arrays, booleans, nulls, and numbers. JSON output uses correct typing — true/false not strings, numbers not quoted, andnull not "null".

How to use

  1. Choose direction — YAML input → JSON output, or JSON input → YAML output — using the toggle bar at the top.
  2. Paste or type your input into the left pane. Conversion happens live within 500ms.
  3. Adjust options in the output pane header: indent (2 spaces, 4 spaces, Tab) and Sort Keys.
  4. Swap direction — clicking the other mode automatically moves the current output back as input.
  5. Copy or Download the result using the buttons in the header or the stats strip below the panes.

Features

⚡ Live conversion

Converts as you type with a 500ms debounce. No button press required.

📄 Multi-document YAML

Handles YAML files with multiple --- separators (common in Kubernetes). Each document is converted and combined into a JSON array.

🔤 Sort Keys

Alphabetically sort all object keys at every nesting depth. Useful for diffing configs or producing canonical output.

🎨 Syntax highlighting

Colour-coded output for both JSON and YAML — keys, strings, numbers, booleans, nulls, comments, and anchors.

↕ Bidirectional swap

Switch direction and the converter automatically re-feeds the current output as the new input — no copy-paste needed.

⬇ Download as file

Save the converted output directly as a .json or .yaml file with one click.

🔒 100% private

All conversion runs locally in your browser using js-yaml. No data is sent to any server.

📐 Custom indent

Choose 2 spaces, 4 spaces, or Tab for the output. The setting persists while you edit.

YAML vs JSON — quick reference

📋 YAML strengths

Human-readable, supports comments, less verbose for nested structures, native multi-document support. Preferred for config files (K8s, GitHub Actions, Spring Boot, Ansible).

📋 JSON strengths

Universal support in every language and framework, strict syntax prevents ambiguity, faster to parse, native to JavaScript and REST APIs. Required by most API clients and databases.

Frequently Asked Questions

Why does YAML boolean 'yes' / 'no' become true / false in JSON?

YAML 1.1 (the widely-deployed version) treats yes, no, on, off, true, false — in any capitalisation — as boolean values. This converter follows that spec, so 'yes' becomes true in JSON. If you need the string 'yes', quote it in YAML: '"yes"'.

What is a multi-document YAML file?

A YAML file can contain multiple independent documents separated by --- (three dashes). This is common in Kubernetes, where a single file might define a Deployment and a Service. This converter detects multiple documents and wraps them in a JSON array.

My YAML has anchors (&) and aliases (*) — will they convert correctly?

Yes. js-yaml resolves anchors and aliases before converting, so the output JSON will contain the fully expanded values. The anchor/alias shorthand itself is not preserved since JSON has no equivalent concept.

Can I convert a Kubernetes YAML manifest to JSON?

Yes. Paste the manifest (single or multi-document) and the converter produces valid JSON. Note that kubectl also accepts JSON natively — you can apply JSON manifests with kubectl apply -f.

Why does JSON → YAML sometimes add extra quotes around strings?

The YAML serialiser quotes strings that would otherwise be interpreted as a different type — for example, a string '"true"' must be quoted to distinguish it from the boolean true. This is correct YAML and round-trips cleanly back to JSON.

Does this support YAML 1.2?

The converter uses js-yaml which implements YAML 1.2 parsing rules by default. The main difference from 1.1 is that 'yes'/'no'/'on'/'off' are no longer booleans in strict 1.2 mode. If your YAML was written for a 1.1 parser (most tools), this could cause differences.

Copied to clipboard!

Complete guide to converting between YAML and JSON

YAML and JSON describe the same kinds of data — maps, lists, strings, numbers and booleans — but they are used in different places. Configuration files, Kubernetes manifests, CI pipelines and Docker Compose files are almost always YAML, because it is comfortable to write by hand and supports comments. APIs, logs and programmatic tooling are almost always JSON, because it is unambiguous and every language parses it out of the box.

Because YAML 1.2 is formally a superset of JSON, converting between them is usually lossless in the direction that matters. This converter runs both ways: paste YAML to get JSON, or paste JSON to get YAML, with the output updating as you type.

You can choose the indentation used in the output, sort keys alphabetically to make two documents easy to compare, and toggle syntax highlighting. Multi-document YAML files, the kind produced by concatenating Kubernetes manifests with the --- separator, are handled and converted into a JSON array.

The conversion runs entirely in your browser using js-yaml. Configuration files often contain internal hostnames, tokens and credentials, so nothing is uploaded or stored.

How it works

YAML input is parsed with js-yaml into ordinary JavaScript values, then serialised with JSON.stringify at your chosen indentation. Because the intermediate representation is plain data, anything YAML can express but JSON cannot — comments, anchors as reusable references, and explicit type tags — is resolved or dropped at that point rather than being copied across.

Anchors and aliases are expanded before serialisation. If your YAML defines an anchor with &name and references it with *name, the JSON output contains a full copy of the value at every reference, because JSON has no concept of a shared reference. The data is identical; the shorthand is not preserved.

A multi-document YAML file is loaded as a list of documents. A single document produces a JSON object, while two or more produce a JSON array with one entry per document, so no data is lost when converting a concatenated manifest.

In the JSON to YAML direction the input is parsed with JSON.parse and dumped as YAML. The dumper adds quotes wherever they are needed to preserve the original type, which is why a string such as yes or 12345 comes back quoted: without the quotes a YAML parser would read it as a boolean or a number.

Common uses

  • Convert a Kubernetes manifest to JSON so it can be sent to the API server directly or processed with jq.
  • Turn a JSON API response into YAML to paste into a configuration file that a human has to read and edit.
  • Normalise two configuration files to the same format with keys sorted, so a diff shows real changes rather than ordering noise.
  • Split a multi-document Kubernetes YAML file into a JSON array for scripting or bulk processing.
  • Convert a docker-compose.yml or GitHub Actions workflow to JSON to inspect its exact structure when a value is not being interpreted as expected.
  • Check whether a YAML file is syntactically valid, since a parse error is reported immediately with the reason.
  • Move a Spring Boot application.yml into JSON form for a tool or environment that only accepts JSON configuration.

Before you rely on the result

  • Comments are lost when converting YAML to JSON, because JSON has no comment syntax. If the comments are documentation you need, keep the YAML file as the source of truth and treat the JSON as generated output.
  • In YAML 1.2 the bare words yes, no, on and off are strings, not booleans. Many tools still follow YAML 1.1, where they are booleans. If a value that used to be true arrives as the string yes, this difference is why. Quote such values explicitly when the meaning matters.
  • A value like 1.10 is a number in both formats and will lose its trailing zero. Version strings, phone numbers, and identifiers with leading zeros should always be quoted in the source YAML so they are treated as strings.
  • Anchors and aliases are expanded, so a YAML file that used one anchor in twenty places produces JSON with twenty copies. The output can be substantially larger than the input, and editing one copy no longer updates the others.
  • Key order is preserved by default but is not guaranteed to be meaningful. JSON objects are formally unordered, so any tool consuming the output may reorder them. Do not rely on order to convey information.
  • Very large files are processed in a single browser thread and can make the tab unresponsive. For files in the tens of megabytes, use a command-line tool such as yq instead.
  • Converting to YAML does not validate against a schema. Valid YAML is not the same as a valid Kubernetes manifest or a valid Compose file — use kubectl apply --dry-run or a schema validator for that.