YAML ↔ JSON Converter

What Is YAML?

YAML — which recursively stands for YAML Ain't Markup Language — is a human-readable data serialization format. It was first proposed in 2001 by Clark Evans, Ingy döt Net, and Oren Ben-Kiki as a friendlier alternative to XML for configuration files and data exchange. YAML uses indentation to denote structure, colons to separate keys from values, and dashes to represent list items. There are no curly braces, no brackets (unless you use inline syntax), and no mandatory quoting — which makes it exceptionally easy to read and write by hand.

A simple YAML document looks like this:

name: Jane Smith
age: 32
skills:
  - JavaScript
  - Python
  - Kubernetes
address:
  city: San Francisco
  state: CA

The equivalent JSON is more verbose but unambiguous — which is exactly the trade-off between the two formats.

YAML vs JSON: A Side-by-Side Comparison

Both YAML and JSON are used to represent structured data, but they serve slightly different niches:

• Readability. YAML wins hands down. Its indentation-based syntax removes visual clutter. JSON requires braces, brackets, and mandatory double-quoting of keys, which adds noise for human readers.
• Parsability. JSON is simpler to parse. Its grammar fits on a napkin. YAML's grammar is far more complex — the full spec runs over 80 pages — and edge cases in YAML parsing have caused real-world security vulnerabilities.
• Comments. YAML supports comments (lines starting with #). JSON does not. This single difference is why many configuration files choose YAML over JSON.
• Data types. JSON has six types: string, number, boolean, null, array, and object. YAML adds timestamps, binary data, and more — though in practice most YAML usage sticks to the same six types JSON supports.
• Multi-document support. A single YAML file can contain multiple documents separated by ---. JSON files contain exactly one value.

YAML Syntax Basics

If you are new to YAML, here are the key syntax rules:

• Key-value pairs: Written as key: value. The space after the colon is mandatory.
• Indentation: Use spaces (never tabs). Two spaces per level is the convention, but any consistent number works.
• Lists: Prefix each item with - (dash followed by a space). Lists can be nested inside mappings and vice versa.
• Strings: Plain (unquoted), single-quoted, or double-quoted. Double-quoted strings support escape sequences like\n and \t.
• Multi-line strings: Use | for literal blocks (preserving newlines) or > for folded blocks (joining lines with spaces).
• Comments: Everything after # on a line is a comment.
• Booleans: true and false (YAML 1.2). Older YAML 1.1 also accepted yes, no, on, off — a frequent source of bugs.
• Null: null, ~, or an empty value.

YAML in DevOps: Where You Will Encounter It

YAML has become the lingua franca of DevOps. Here are the most common places you will encounter YAML files:

Docker Compose

Docker Compose uses docker-compose.yml to define multi-container applications. Services, networks, volumes, environment variables, and port mappings are all specified in YAML.

Kubernetes

Kubernetes manifests — Deployments, Services, ConfigMaps, Ingresses, and every other resource — are written in YAML (or JSON, but YAML is the de facto standard in the Kubernetes community). A single cluster might have thousands of YAML files defining its desired state.

GitHub Actions

GitHub Actions workflows live in .github/workflows/*.yml. They define triggers, jobs, steps, and environment variables — all in YAML.

Ansible

Ansible playbooks, roles, and inventory files are YAML. Ansible was one of the earliest tools to bet on YAML for infrastructure configuration, and it helped popularize the format in the DevOps world.

CI/CD Pipelines

GitLab CI (.gitlab-ci.yml), CircleCI (.circleci/config.yml), Azure Pipelines (azure-pipelines.yml), and many other CI/CD systems use YAML for pipeline definitions.

YAML Gotchas: Common Pitfalls

YAML's flexibility comes with several well-known traps:

The Norway Problem

In YAML 1.1, the values NO, no, Yes, and yes are interpreted as booleans, not strings. This means that a list of country codes like [DK, FI, NO, SE] becomes ["DK", "FI", false, "SE"] — Norway disappears. The fix is to quote values that could be misinterpreted: "NO". YAML 1.2 removed this behavior, but many parsers still default to YAML 1.1 rules.

Indentation Sensitivity

A single wrong space can change the structure of your document. Unlike JSON, where braces make nesting explicit, YAML relies entirely on whitespace. Tabs are forbidden — only spaces are allowed — and mixing indentation levels within a document produces parse errors or silent misinterpretation.

Implicit Typing

YAML tries to infer types. The value 1.0 becomes a float, 010 becomes an octal integer (8 in YAML 1.1), and 2024-01-15 becomes a date object in some parsers. If you want these to remain strings, quote them.

When to Use YAML vs JSON vs TOML

Choosing the right format depends on the use case:

• YAML — Best for human-edited configuration files where comments and readability matter. The dominant choice in Kubernetes, CI/CD, and infrastructure-as-code.
• JSON — Best for machine-to-machine data exchange, APIs, and any context where you need strict, unambiguous parsing. Every language has a fast, battle-tested JSON parser.
• TOML — Best for simpler configuration files. Used by Rust's Cargo.toml, Python's pyproject.toml, and Hugo. TOML avoids YAML's implicit typing problems while remaining readable.

YAML Versions: 1.1 vs 1.2

YAML 1.1 (2005) and YAML 1.2 (2009) differ in several important ways:

• YAML 1.2 removed boolean aliases (yes, no,on, off). Only true and false are booleans.
• YAML 1.2 removed octal literals with a leading zero (010 is just the number ten, not eight).
• YAML 1.2 is a strict superset of JSON, meaning every valid JSON document is also valid YAML 1.2. This was not true in YAML 1.1.

Most modern tools (Kubernetes, GitHub Actions, etc.) use parsers that lean toward YAML 1.1 behavior, so be aware of the differences when debugging unexpected type conversions.

Frequently Asked Questions

Is this tool safe to use with sensitive data?

Yes. This converter runs entirely in your browser. No data is transmitted to any server. You can verify this by opening your browser's Network tab — you will see zero requests during conversion.

Does this support all YAML features?

This tool supports the most common YAML features: key-value pairs, nested objects, arrays, strings (plain, single-quoted, double-quoted), multi-line strings (literal and folded blocks), numbers, booleans, null, comments, and inline collections. Advanced features like anchors (&), aliases (*), tags (!), and merge keys are not supported in this lightweight parser.

Why does my YAML parse differently than expected?

The most common causes are: implicit type conversion (e.g., no becoming false), indentation errors, or unquoted strings that look like numbers or dates. When in doubt, quote your values with double quotes.

Can I convert multi-document YAML?

This tool processes a single YAML document. If your input contains the document separator ---, it will be stripped and the first document will be parsed.

What is the maximum input size?

Since this tool runs in your browser, the limit is your browser's available memory. In practice, inputs up to several megabytes convert without any issues.

How do I handle YAML files with tabs?

YAML does not allow tab characters for indentation — only spaces. If your file contains tabs, replace them with spaces (typically two per indent level) before converting.