YAML to JSON Converter and JSON to YAML

YAML and JSON: A Complete Conversion Guide

What this tool does

This is a real, bidirectional converter between two of the most common data-serialization formats used in modern software: YAML (YAML Ain't Markup Language) and JSON (JavaScript Object Notation). Paste YAML and the tool parses it into a data structure and re-emits it as pretty-printed JSON. Paste JSON and it parses that and emits clean, indented YAML. A direction toggle and a swap button let you round-trip data both ways without retyping anything.

The conversion is performed entirely in your browser using a battle-tested open-source parser, so your data never travels to our server. There is no upload, no logging, and no storage of the content you paste. That makes the tool safe for configuration files, API payloads, and other data you would rather not send across the network. Because the parse is real and not a string hack, invalid input produces an honest, specific error message that points at the line and reason, instead of silently mangling your data.

What is YAML?

YAML is a human-friendly data-serialization language designed to be easy to read and write. Instead of braces and brackets, YAML uses indentation (spaces, never tabs) to express structure, which makes nested data feel like an outline. A simple YAML document looks like this:

name: ShowMyIP
version: 2
tools:
  - YAML to JSON
  - JSON to YAML
settings:
  theme: dark
  beta: true

YAML supports the same core data types you find in most languages: scalars (strings, numbers, booleans, and null), sequences (ordered lists), and mappings (key/value dictionaries). It adds conveniences that JSON lacks, such as comments (lines starting with #), multi-line block scalars for long text, anchors and aliases for reusing chunks of data, and the ability to put multiple documents in one file separated by ---. These features are why YAML dominates the world of configuration: Kubernetes manifests, Docker Compose files, GitHub Actions and GitLab CI pipelines, Ansible playbooks, and countless application config files are all written in YAML.

YAML's readability comes with trade-offs. Indentation is significant, so a single misplaced space can change the meaning of a document or break the parse entirely. Tabs are forbidden for indentation. And YAML's type inference can surprise you: the classic "Norway problem" is that an unquoted NO or no is interpreted as the boolean false, and version strings or ZIP codes can be silently coerced into numbers. When precision matters, quote your scalars.

What is JSON?

JSON is a lightweight, language-independent data-interchange format derived from JavaScript object syntax. It uses explicit punctuation, curly braces for objects, square brackets for arrays, colons between keys and values, and commas between elements, which makes its structure unambiguous to both machines and humans. The same data shown above looks like this in JSON:

{
  "name": "ShowMyIP",
  "version": 2,
  "tools": [
    "YAML to JSON",
    "JSON to YAML"
  ],
  "settings": {
    "theme": "dark",
    "beta": true
  }
}

JSON's data types are strings, numbers, booleans, null, arrays, and objects. It deliberately keeps the feature set small: there are no comments, no trailing commas, no single quotes (strings must use double quotes), and every key in an object must be a quoted string. This minimalism is a feature. JSON is trivial to parse, it is supported natively by virtually every programming language, and it is the default payload format for REST and most web APIs. If YAML is the language of configuration, JSON is the language of data on the wire.

YAML vs JSON: how they relate

Here is the key insight that makes conversion reliable: JSON is a subset of YAML. Every valid JSON document is also valid YAML, which means YAML parsers can read JSON directly. The two formats describe the same underlying data model: scalars, lists, and key/value maps. That shared model is exactly why a lossless round-trip is usually possible. When you convert YAML to JSON, you are projecting the data into the stricter, punctuation-based syntax; when you convert JSON to YAML, you are re-expressing it in the indentation-based syntax.

The differences that matter in practice are about expressiveness, not data. YAML can carry comments, anchors, custom tags, and multiple documents; JSON cannot. So a YAML-to-JSON conversion will drop comments and resolve anchors into their expanded values, because JSON has no place to put them. Going the other direction, JSON-to-YAML, is essentially always lossless because JSON uses fewer features than YAML supports. Understanding this asymmetry helps you predict what a conversion will and will not preserve.

YAML type coercion and the "Norway problem"

The most common surprise when you convert YAML to JSON is how YAML guesses the type of unquoted scalars. Because YAML tries to be helpful, a bare value that looks like a number, a boolean, or null is converted into that type rather than a string. This is great for readability but it bites people who did not expect it. The famous example is the "Norway problem": a list of country codes written as unquoted values turns the entry for Norway, NO, into the boolean false, because older YAML rules treated yes, no, on, and off as booleans. Modern parsers following the YAML 1.2 / JSON-compatible schema are stricter, but the lesson still holds for any value whose meaning depends on staying a string.

Consider this YAML and the JSON it produces:

country: NO
zip: 01234
version: 1.20
released: true
note: null

After conversion, version becomes the number 1.2 (the trailing zero is gone), zip may lose its leading zero, released becomes a real boolean, and note becomes JSON null. If any of those needed to stay text, the fix is simple: wrap the value in quotes in your YAML, for example zip: "01234" and version: "1.20". Quoting forces the scalar to be a string, and the converted JSON will then contain "01234" and "1.20" exactly as written. Whenever a converted value looks wrong, type coercion is the first thing to check.

Common conversion errors and how to fix them

This converter reports the parser's real error message instead of failing silently, so the fix is usually quick once you know what each message means. The most frequent issues are:

• Tabs used for indentation. YAML forbids tab characters for indentation; you must use spaces. If your editor inserted tabs, the parser throws a message about a tab character. Configure the editor to insert spaces, or convert tabs to spaces, and re-run.
• Inconsistent indentation. Every level of nesting must be indented consistently. Mixing two-space and four-space indents under the same parent confuses the parser. Pick one indent width and keep it uniform.
• Missing space after a colon. In YAML a mapping needs a space after the colon, so key:value is wrong and key: value is right. The same applies to list items, which need a space after the dash.
• Unquoted special characters. Values containing a leading @, %, *, &, {, or a colon followed by a space can be misread. Quote such values to be safe.
• Invalid JSON when going the other way. When converting JSON to YAML, the input must be strict JSON: double-quoted keys and strings, no trailing commas, and no comments. A message like "Unexpected token" or "Expected property name" usually means a single quote, a trailing comma, or a stray comment slipped in. If your source is loose JavaScript-style object notation, clean it up (the JSON Formatter & Validator is handy for this) before converting.

Working with multi-document YAML

YAML can pack several independent documents into a single file, separated by a line containing three dashes (---). This is extremely common in Kubernetes, where one file might define a Deployment and a Service together:

---
kind: Deployment
metadata:
  name: web
---
kind: Service
metadata:
  name: web-svc

JSON has no concept of multiple documents in one value; a JSON file is a single value. So when you need to convert a multi-document YAML file, convert one document at a time, pasting the block between two --- markers, to get a clean single JSON object for each. If you genuinely need all documents in one JSON payload, wrap them in a JSON array yourself after converting each piece. Knowing this up front avoids the confusion of seeing only the first document appear in your output.

When to convert between YAML and JSON

Conversion is a daily task for developers, DevOps engineers, and anyone who works with configuration and APIs. Common scenarios include:

• API testing with config files. Your service is configured in YAML, but the API it talks to expects JSON. Convert a YAML fixture to JSON to use it as a request body in a tool like Postman or curl.
• Reading API responses comfortably. An API returns dense, minified JSON. Convert it to YAML to skim a large payload with less visual noise and proper indentation while you debug.
• Migrating configuration. You are moving a project from a JSON-based config (for example, a tsconfig.json or a package.json fragment) to a YAML-based system, or vice versa, and need a faithful starting point instead of retyping by hand.
• Infrastructure as code. Kubernetes, Helm, Docker Compose, and CI pipelines use YAML, but many tooling and validation steps work in JSON. Converting lets you validate a manifest with JSON-schema tooling or feed it to a JSON-only utility.
• Generating fixtures and seed data. Write data in YAML because it is pleasant to author, then convert to JSON for the database seeder, mock server, or test that expects JSON.
• Learning and documentation. Showing the same structure in both formats side by side is a great way to teach the differences, and a converter makes producing those examples instant.
• Editing OpenAPI and Swagger specs. API specifications are often authored in YAML for readability but consumed by tooling that expects JSON. Convert your OpenAPI YAML to JSON to feed a code generator, mock server, or validator that only accepts the JSON form.
• Translating CI/CD pipelines. GitHub Actions, GitLab CI, and CircleCI use YAML. Converting a pipeline to JSON lets you diff it programmatically, run it through a JSON-schema linter, or store a normalized copy alongside other JSON config.
• Inspecting Helm values. Helm charts use a values.yaml file. Converting it to JSON makes it easy to query specific keys with a JSON tool or to compare two releases field by field.

How to use this converter

1. Choose a direction with the toggle at the top: YAML to JSON or JSON to YAML. You can switch at any time.
2. Paste or type your data into the input box. Click Load sample if you want a working example to experiment with.
3. Press Convert. The result appears in the output panel below, pretty-printed and indented.
4. Click Copy to put the output on your clipboard, or use Swap to move the output back into the input and flip the direction, which is handy for verifying a round-trip.
5. If your input is malformed, a red message explains exactly what went wrong (for example, an unexpected character, bad indentation, or a missing quote) so you can fix it quickly.

Everything happens locally and instantly. There is no submit-and-wait round trip to a server, and nothing you paste is transmitted or retained.

Understanding conversion results and edge cases

A few behaviors are worth knowing so the output never surprises you:

• Comments are not preserved when converting YAML to JSON. JSON has no comment syntax, so any # comments in your YAML are dropped. The data is intact; only the annotations are gone.
• Anchors and aliases are expanded. If your YAML reuses a block with &anchor and *alias, the converter resolves those references and writes the full, expanded value into the JSON output.
• Type coercion follows the YAML spec. Unquoted true, false, null, and numeric-looking values become booleans, null, and numbers. If you need a literal string like the word "true" or a leading-zero ZIP code, quote it in your YAML.
• Key order is generally preserved for mappings, so the output reads in the same order you wrote it.
• Multi-document YAML. A file with several --- separated documents represents more than one JSON value; convert one document at a time for a single, clean JSON result.
• JSON to YAML is lossless in normal use because JSON relies on a smaller feature set than YAML offers.

Privacy and security

This tool is client-side by design. The YAML and JSON parsing both run in your browser using the open-source js-yaml library and the browser's built-in JSON engine. Your content is never uploaded, so configuration files containing internal hostnames, tokens you are rotating, or other sensitive structure stay on your machine. As a general habit, avoid pasting live secrets into any online tool; even though this one keeps your data local, treating secrets carefully is always the safer default. The output is rendered as plain text, never executed, so converting an untrusted payload cannot run code on your page.

Related tools and further reading

If you are working with JSON specifically, the JSON Formatter & Validator will beautify, minify, and validate your JSON and pinpoint syntax errors. To understand JSON's rules from the ground up, including data types, escaping, and common mistakes, read JSON syntax explained. Together with this converter, those resources cover most of the day-to-day work of moving structured data between human-friendly and machine-friendly representations.