JSON to YAML Converter

JSON and YAML describe the same kinds of data, but they suit different jobs. APIs and browsers speak JSON, while Kubernetes manifests, Docker Compose files, GitHub Actions workflows and many OpenAPI specifications are written in YAML. Our free JSON to YAML converter works in both directions using the open-source yaml library, which follows YAML 1.2. Choose two or four spaces of indentation, see errors with the exact line and column, convert multi-document YAML into a JSON array, split a top-level JSON array into separate YAML documents, and expand anchors and aliases safely. Everything runs in your browser.

How to use the JSON to YAML

1. 1 Pick a directionChoose JSON to YAML or YAML to JSON. The input box on the left accepts the source format and the output appears on the right as you type.
2. 2 Paste your dataPaste a configuration file, an API response or a manifest. If the input cannot be parsed, the error message shows the line and column where the parser stopped.
3. 3 Set the indentationChoose two or four spaces. Two spaces is the usual convention for Kubernetes, Docker Compose and GitHub Actions files, and is the safer default.
4. 4 Handle multiple documentsYAML with several documents separated by three dashes becomes a JSON array of documents. Going the other way, tick the split option to turn each item in a top-level JSON array into its own YAML document.
5. 5 Copy or download the resultCopy the output to your clipboard or download it as a file, then check it in the tool that will actually read it, such as kubectl, Docker or your CI system.

JSON and YAML: the same data, different styles

JSON uses braces for objects, square brackets for arrays and double quotes around every key and string. It is strict, compact and easy for programs to produce and parse, which is why almost every web API uses it. YAML represents the same objects, lists, strings, numbers, booleans and nulls, but relies on indentation and line breaks instead of brackets, and most strings do not need quotes. That makes YAML easier for people to read and edit by hand, and it allows comments, which JSON does not.

YAML 1.2 was designed so that JSON is effectively a subset of it. In practice that means any valid JSON document can be read by a YAML 1.2 parser, and converting JSON to YAML never loses data. The reverse is not always true: YAML has features such as comments, anchors and aliases, custom tags and multiple documents in one file that have no direct equivalent in JSON, so converting YAML to JSON involves some choices, which are explained below.

The converter keeps the order of keys as they appear in your input, so a manifest or a configuration file comes out in the same order you wrote it. Numbers, booleans and null values keep their types rather than being turned into strings.

Where you will meet YAML

If you work with modern infrastructure or automation, YAML is hard to avoid. Converting from JSON is useful when you have generated data, an API response or an example from documentation and need to drop it into one of these files. Converting to JSON is useful when a script, a validator or an API only accepts JSON.

• Kubernetes: deployments, services, config maps and other resources are usually written as YAML manifests, often several documents in one file separated by three dashes.
• Docker Compose: the compose file that defines services, networks and volumes is YAML, and environment blocks are a common source of quoting problems.
• GitHub Actions and other CI systems: workflows, jobs and steps are defined in YAML files kept in the repository.
• OpenAPI and Swagger: API specifications can be written in JSON or YAML, and many teams write YAML by hand and publish JSON for tools.
• Static site generators and application settings: front matter, translation files and configuration for many frameworks use YAML.

YAML 1.1 versus YAML 1.2 gotchas

Not every YAML parser follows the same version of the specification, and the differences matter. This converter uses YAML 1.2, but some widely used tools still behave like YAML 1.1 parsers. The best known example is the so-called Norway problem. Under YAML 1.1, unquoted values such as yes, no, on and off are read as booleans, so a list of country codes containing NO for Norway can silently become false. Under YAML 1.2 only true and false are booleans, and yes, no, on and off stay as plain strings.

Numbers have similar traps. A YAML 1.1 parser reads a value with a leading zero, such as 0755, as an octal number, giving 493, while YAML 1.2 treats it as the decimal 755 and writes octal with a 0o prefix instead. Values such as phone numbers, postcodes with leading zeros or version strings like 1.10 can also be misread as numbers and lose their formatting. Some YAML 1.1 parsers even read times such as 1:30 as base-60 numbers.

The safe habit is simple: if a value must stay a string, put it in quotes. When converting JSON to YAML, the converter quotes strings that a YAML 1.2 parser would otherwise read as numbers, booleans or null, such as "1.10" or "0755". Words like yes, no, on and off are already plain strings under YAML 1.2, so they may be left unquoted in the output. If the file will be read by a tool that follows YAML 1.1 rules, add quotes around those values yourself.

Indentation, tabs and quoting rules

Indentation is part of the structure in YAML. Items at the same level must line up exactly, and nested items must be indented further than their parent. Tabs are not allowed for indentation at all, so a YAML file that looks fine in one editor can fail to parse because a tab has crept in. If you see an error about indentation or an unexpected character at the start of a line, check for tabs and mixed spacing first. Most code editors can show whitespace characters and convert tabs to spaces.

Most strings in YAML can be written without quotes, but some characters change the meaning of a line. A colon followed by a space starts a key and value, a hash after a space starts a comment, and characters such as square brackets, braces, an ampersand, an asterisk, an exclamation mark or a percent sign at the start of a value have special meanings. Single quotes treat everything literally, and a single quote inside is written as two single quotes. Double quotes allow escape sequences such as a newline written as a backslash followed by n. When in doubt, quote the value.

For long text, YAML offers block scalars. A pipe character keeps line breaks exactly as written, which suits scripts and certificates, while a greater-than sign folds lines into a single paragraph. When converting to JSON these become ordinary strings, with line breaks written as escape sequences.

Multiple documents, anchors and comments

A single YAML file can contain several documents separated by a line of three dashes. Kubernetes uses this heavily, for example to keep a deployment and its service in one file. JSON has no such idea, so when you convert multi-document YAML the converter produces a JSON array with one element per document. Going the other way, the split option turns each element of a top-level JSON array into its own YAML document, which is a quick way to build a multi-resource manifest from generated data.

Anchors and aliases let YAML reuse a block: an ampersand defines an anchor and an asterisk refers back to it, which is common in Docker Compose and CI files to avoid repeating shared settings. JSON cannot express references, so the converter expands each alias into a full copy of the data it points to. Expansion has a safety limit, because a deliberately crafted file can use nested aliases to grow into an enormous document from a few lines of text. If the limit is reached, you see an error rather than a frozen browser tab.

Comments are the other casualty. JSON has no comment syntax, so any comments in your YAML are dropped when you convert it to JSON, and converting that JSON back to YAML will not bring them back. If the comments explain important settings, keep the original YAML file as the master copy and treat the JSON as generated output.

Errors, large numbers and privacy

When the input cannot be parsed, the converter shows the parser message with the line and column. As with most parsers, the reported position is where the problem was noticed, which may be just after the real mistake, such as a missing closing quote on the previous line or a list item indented by one space too few. Fix the first error and check again, because one mistake can hide others further down.

Very large integers deserve a mention. JavaScript represents numbers in a way that cannot store whole numbers above 9,007,199,254,740,991 exactly, so an ID longer than that in your JSON may be rounded during conversion. If you work with long numeric identifiers, store them as strings in the source data.

The conversion runs entirely in your browser. Nothing you paste is sent to a server, logged or stored, which matters because configuration files often contain internal hostnames, connection strings or secrets. Even so, it is good practice to remove passwords, tokens and keys before sharing a converted file with anyone else, or before pasting it into any online tool.

Examples you can copy

JSON:
{
  "service": "web",
  "replicas": 2,
  "ports": [80, 443],
  "version": "1.10"
}

YAML (2 spaces):
service: web
replicas: 2
ports:
  - 80
  - 443
version: "1.10"

YAML:
kind: Deployment
name: web
---
kind: Service
name: web

JSON:
[
  { "kind": "Deployment", "name": "web" },
  { "kind": "Service", "name": "web" }
]

YAML:
defaults: &defaults
  restart: always
  region: london
app:
  image: shop
  settings: *defaults

JSON:
{
  "defaults": { "restart": "always", "region": "london" },
  "app": {
    "image": "shop",
    "settings": { "restart": "always", "region": "london" }
  }
}

Common mistakes to avoid

Frequently asked questions