Last updated: June 2025 · 13 min read
YAML is everywhere in modern development — Docker Compose, Kubernetes, GitHub Actions, CI/CD pipelines, and countless application config files. But when you need to process YAML data programmatically, convert it for an API, or debug a configuration issue, converting it to JSON is often the fastest path forward.
This guide provides a complete YAML syntax reference, covers the most common parsing errors (and how to fix them), and explains when and how to convert YAML to JSON effectively.
→ Try Our Free YAML to JSON ConverterYAML uses indentation to define hierarchical structure. Each indentation level (typically 2 spaces) represents a nesting level. Keys and values are separated by a colon followed by a space.
# Basic key-value pairs name: MyApp version: 1.0.0 description: A sample application # Nested objects (indentation = nesting) database: host: localhost port: 5432 name: production # Lists (use hyphen + space) features: - authentication - logging - caching
| Type | YAML Syntax | JSON Equivalent |
|---|---|---|
| String | text or "quoted" | "text" |
| Integer | 42 | 42 |
| Float | 3.14 | 3.14 |
| Boolean | true / false | true / false |
| Null | null or ~ | null |
| Array | - item (or [a, b]) | [...] |
| Object | key: value (indented) | {...} |
| Inline Array | [one, two, three] | ["one","two","three"] |
| Inline Object | {a: 1, b: 2} | {"a":1,"b":2} |
YAML has powerful multi-line string support using block scalars:
# Literal block (|) — preserves newlines exactly description: | Line one Line two Line three # Folded block (>) — converts single newlines to spaces summary: > This is a long sentence that will be folded into a single line in the output. # Strip trailing newline (|- or >-) script: |- #!/bin/bash echo "hello" # Keep trailing newlines (|+ or >+) output: |+ Two blank lines follow
YAML's anchor/alias system lets you define content once and reference it multiple times:
# Define an anchor with & defaults: &defaults timeout: 30 retries: 3 # Reference with * service_a: <<: *defaults # Merge defaults host: api-a.com service_b: <<: *defaults host: api-b.com timeout: 60 # Override specific key
# Tags (explicit types)
port: !!int "8080" # Force integer type
is_active: !!bool "true" # Force boolean type
# Document separator
---
document: 1
---
document: 2
# Complex keys (quoted)
"user@example.com":
role: admin
# Flow vs Block style
# Block (default, readable):
servers:
- name: web1
ip: 10.0.0.1
- name: web2
ip: 10.0.0.2
# Flow (compact, JSON-like):
servers: [{name: web1, ip: 10.0.0.1}, {name: web2, ip: 10.0.0.2}]
Cause: A colon (:) is being interpreted as a key-value separator when it's part of a value (e.g., in a URL, time, or sentence).
Fix: Quote the value:
# ❌ Error time: 12:30:00 url: https://example.com:8080 # ✅ Fixed time: "12:30:00" url: "https://example.com:8080"
Cause: Inconsistent indentation. YAML is very strict about alignment — each nesting level must be indented consistently.
Fix: Ensure all items at the same level have identical indentation:
# ❌ Error (inconsistent indentation) server: host: localhost port: 8080 # Extra space! # ✅ Fixed server: host: localhost port: 8080
Cause: Special characters (like @, #, {, }, [, ], ,) appear unquoted in a value.
Fix: Wrap the value in quotes:
# ❌ Error pattern: [a-z]+ comment: This # is not a comment # ✅ Fixed pattern: "[a-z]+" comment: "This # is not a comment"
Cause: Mixing YAML 1.1 and 1.2 features, or using a parser that only supports one version.
Fix: Add the YAML version directive at the top, or use a parser that supports your YAML version:
%YAML 1.2 --- # Content here
Cause: Using tab characters instead of spaces for indentation.
Fix: Replace all tabs with spaces (2 spaces per level is the convention):
# ❌ Error (tabs used) server: host: localhost # ✅ Fixed (2 spaces) server: host: localhost
YAML's automatic type detection is convenient but can cause unexpected behavior. Here are the most common surprises:
| YAML Value | Parsed As | Why It Matters |
|---|---|---|
true | Boolean | Can't be used as a string "true" |
false | Boolean | Same issue |
yes, no | Boolean (YAML 1.1) | Not in YAML 1.2, but many parsers still do this |
on, off | Boolean (YAML 1.1) | Can break config that expects string |
12345 | Integer | ZIP codes, phone numbers need quoting |
1.2.3 | String | Not a number, but could confuse parsers |
2025-01-15 | Date | ISO dates auto-convert to Date objects |
0x1A | Integer (26) | Hex notation auto-converts |
.inf | Float (Infinity) | Mathematical infinity, not a string |
null, ~ | Null | Empty value, not the string "null" |
'...' prevent all special character interpretation. Double quotes "..." allow escape sequences like \n. For maximum safety, use single quotes.
Most REST APIs expect JSON request bodies. If your configuration or data is in YAML, converting to JSON is necessary before sending API requests.
When a YAML file isn't behaving as expected, converting it to JSON reveals exactly how the parser interpreted your data — types, structure, and any surprises from automatic type coercion.
Many data processing tools work with JSON natively. Converting YAML input to JSON at the pipeline entry point simplifies downstream processing.
While most languages have YAML parsers, JSON parsing is universally fast and reliable. Converting YAML to JSON before passing data between services eliminates parser compatibility issues.
JSON Schema is more mature and widely supported than YAML schema validation. Converting to JSON lets you validate against existing JSON Schemas.
--- and separate documents clearly.When you convert YAML to JSON, several transformations occur:
Key differences in the output:
\n escape sequences.---) are not represented in JSON.This error means a colon (:) in your YAML is being interpreted as a key-value separator when it shouldn't be. Fix by quoting the string containing the colon, or ensuring the colon after a key has a space after it.
Common reasons: inconsistent indentation (mixing tabs and spaces), unquoted special characters, incorrect list syntax, or invalid YAML version. Use a linter like yamllint to identify the exact issue.
No. YAML specification forbids using tabs for indentation — you must use spaces. Most YAML parsers will reject files with tabs. Use 2 spaces per indentation level as the standard convention.
Use the pipe (|) character for literal newlines (preserves line breaks) or greater-than (>) for folded newlines (converts single newlines to spaces). Add a chomping indicator (+ or -) to control trailing newlines.
YAML uses indentation for structure and supports comments, anchors, and multi-line strings. JSON uses braces/brackets and is more strict. YAML is a superset of JSON — all valid JSON is valid YAML.
YAML's flexibility makes it powerful for configuration, but that same flexibility can lead to parsing errors and type coercion surprises. Converting YAML to JSON is an invaluable debugging technique that reveals exactly how your YAML is being interpreted.
Our free YAML to JSON converter runs entirely in your browser — paste your YAML, get instant JSON output with proper formatting. It handles anchors, aliases, multi-line strings, and type coercion correctly, so you can focus on your work instead of fighting with parsers.