YAML to JSON Converter

About YAML to JSON Converter

YAML vs JSON - When to Use Each

JSON is stricter and faster to parse, while YAML is more human-readable and supports comments. Pick JSON for machine-to-machine data exchange and YAML for config files that humans edit by hand.

Both YAML and JSON represent the same data structures (objects, arrays, strings, numbers, booleans, null), but they target different use cases.

Feature	YAML	JSON
Readability	Very high - minimal syntax noise	Good - but brackets and quotes add visual clutter
Comments	Yes (# comments)	No (not part of the spec)
Quoting strings	Optional for most strings	Required for all strings and keys
Multi-line strings	Built-in (| and > blocks)	No - must use \n escape sequences
Parsing speed	Slower (indentation-based)	Faster (simple grammar)
Language support	Good (libraries in all major languages)	Universal (native in JavaScript, built-in in most languages)
Common use	Config files, CI/CD, Kubernetes, Ansible	APIs, data exchange, package metadata

Where YAML Configuration Is Standard

Tool/Platform	Config File	What It Configures
Docker Compose	docker-compose.yml	Multi-container application stacks
Kubernetes	*.yaml manifests	Pods, deployments, services, ingresses
GitHub Actions	.github/workflows/*.yml	CI/CD pipelines
GitLab CI	.gitlab-ci.yml	CI/CD pipelines
Ansible	playbooks/*.yml	Server provisioning and automation
Terraform	*.tf (HCL, not YAML) but can use YAML for data	Infrastructure as code
Jekyll / Hugo	Front matter and _config.yml	Static site generators
ESLint	.eslintrc.yml	Linting rules (alternative to JSON/JS config)
Swagger/OpenAPI	openapi.yaml	API specifications

YAML Syntax Quick Reference

YAML Syntax	JSON Equivalent	Notes
key: value	{"key": "value"}	Basic key-value pair
parent:\n child: value	{"parent": {"child": "value"}}	Nesting via indentation (2 spaces typical)
- item1\n- item2	["item1", "item2"]	Array items prefixed with dash
count: 42	{"count": 42}	Numbers are auto-detected
active: true	{"active": true}	Booleans: true, false, yes, no, on, off
value: null	{"value": null}	Null: null, ~, or empty value
text: "hello: world"	{"text": "hello: world"}	Quote strings containing special characters
# comment	(no equivalent)	Comments are stripped during conversion

Common YAML Pitfalls

Pitfall	What Happens	Fix
Tabs for indentation	YAML spec forbids tabs - parser error	Use spaces only (2 or 4 per level)
Norway problem: NO as value	YAML 1.1 interprets NO as boolean false	Quote it: "NO" or use YAML 1.2 parser
Unquoted colon in value	key: value: more breaks parsing	Quote the value: key: "value: more"
Inconsistent indentation	Child misaligned with siblings	Use a consistent indent (2 spaces is standard)
Version string 1.0	Parsed as number 1 (integer)	Quote it: version: "1.0"
Trailing spaces	Can cause unexpected multi-line values	Configure editor to strip trailing whitespace

The "Norway problem" is the most famous YAML gotcha. Country codes like NO, boolean-like strings like on/off/yes/no, and version numbers like 3.10 (parsed as 3.1) all need quoting. YAML 1.2 fixed the boolean problem by only recognizing true/false, but many parsers still use YAML 1.1 rules.

What This Parser Handles

Feature	Supported	Notes
Key-value pairs	Yes	Standard scalar keys
Nested objects	Yes	Via indentation
Arrays (- syntax)	Yes	Sequence items
Strings (quoted/unquoted)	Yes	Single and double quotes
Numbers, booleans, null	Yes	Auto-detected types
Comments (#)	Yes	Stripped during conversion
Anchors and aliases (&/*)	No	Use a full YAML library (js-yaml)
Multi-line strings (| and >)	No	Use a full YAML library
Multi-document (---)	No	Single document only
Flow style ({key: val})	No	Use block style instead

YAML Specification Versions

Most production YAML parsers target either the YAML 1.1 (2005) or YAML 1.2 (2009) specification, and the two differ in ways that bite real projects.

Version	Released	Key Behaviour
YAML 1.0	January 2004	Original draft, largely of historical interest only
YAML 1.1	January 2005	Widely deployed for a decade. Treats yes/no/on/off as booleans. Source of the "Norway problem".
YAML 1.2	October 2009	Aligned with JSON as a strict superset. Only true/false are booleans. Cleaner type system.
YAML 1.2.2	October 2021	Editorial revision, no normative changes. Current reference spec.
YAML 1.3	Under development	Announced by yaml.io, still draft as of 2026

PyYAML, the most popular YAML library for Python, still defaulted to YAML 1.1 rules until PyYAML 6.0 shipped in October 2021. Ruby's Psych, Go's gopkg.in/yaml.v2, and many JavaScript parsers also shipped with 1.1 semantics for years. That is why boolean-like strings still cause surprise failures in 2026 config files that look perfectly valid.

Worked Example: Parsing a GitHub Actions Workflow

GitHub Actions workflows are a realistic test of a YAML to JSON converter. Here is a trimmed example and the JSON it produces.

YAML input:

name: CI
on:
  push:
    branches: [main]
jobs:
  test:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - run: npm test

JSON output:

{
  "name": "CI",
  "on": {
    "push": {
      "branches": ["main"]
    }
  },
  "jobs": {
    "test": {
      "runs-on": "ubuntu-latest",
      "steps": [
        {"uses": "actions/checkout@v4"},
        {"run": "npm test"}
      ]
    }
  }
}

Note how the YAML "on" key becomes a string key in JSON. In YAML 1.1 parsers, unquoted "on" is interpreted as the boolean true, which is why GitHub Actions workflow validators complain about "true is not a valid event". The fix is quoting: "on":. This is the Norway problem in disguise.

Data Size and Performance

JSON is almost always smaller on the wire than equivalent YAML once you account for indentation. A 10,000-line Kubernetes manifest in YAML is typically 15-30% smaller when rendered as compact JSON, and 5-10% larger when rendered as pretty-printed JSON. Parsing speed also favours JSON by roughly an order of magnitude on most platforms because JSON has a simple context-free grammar while YAML requires tracking indentation state.

For developer-facing configs where file size and parse time do not matter, YAML's readability wins. For machine-to-machine APIs that run at scale, JSON wins. That is why Kubernetes accepts both formats at the API server but stores everything as JSON internally.

Common Conversion Gotchas

YAML-to-JSON round-tripping is not always lossless. The conversion strips comments, normalises whitespace, and loses the distinction between single-quoted, double-quoted, and plain scalars. If your YAML relies on anchors and aliases (for example a shared set of default values referenced across multiple services), the expanded JSON will contain the duplicated values - the reference structure is gone.

Watch for these specific cases when converting:

• Numeric-looking strings: a key like version: 1.10 parses as the number 1.1 in most parsers. Quote it as "1.10" to preserve the trailing zero.
• Leading zeros: code: 007 may be parsed as octal in YAML 1.1 (resulting in 7) but as the string "007" in YAML 1.2. Quote to be safe.
• Timestamps: YAML 1.1 auto-parses ISO 8601 timestamps into datetime objects. JSON has no native date type, so the output is a string. Watch for timezone shifts in this conversion.
• Very large numbers: JavaScript's JSON.parse loses precision beyond Number.MAX_SAFE_INTEGER (2^53 - 1). If your YAML has large IDs, treat them as strings on both sides.

The JSON Formatter is useful for inspecting the output and catching structural surprises. For the inverse problem of turning XML configs into JSON, the XML to JSON Converter handles that format, and the Base64 Encoder/Decoder is handy when your YAML contains encoded secrets you need to inspect.

Why YAML Dominates DevOps Config Files

Nearly every major DevOps and cloud-native tool released since 2014 has picked YAML as its default configuration format. Kubernetes manifests, Docker Compose files, GitHub Actions and GitLab CI pipelines, Ansible playbooks, Helm charts, and OpenAPI specifications are all YAML by default. The common thread is that these files are edited by humans in source control, reviewed in pull requests, and diffed line by line - situations where YAML's support for comments and minimal syntax pays off.

JSON, by contrast, dominates where the producer and consumer are both machines: REST and GraphQL API payloads, package metadata (package.json, composer.json), browser-to-server communication, and structured logging. When a human does need to read JSON, they usually run it through a formatter first, which is effectively admitting that raw JSON is hard to skim.

A useful rule of thumb: if humans write the file more often than machines read it, YAML is the better fit. If machines exchange the data more often than humans inspect it, JSON wins. Tools like Kubernetes that sit at the boundary accept YAML on input and serialise to JSON internally, which is exactly what this converter helps you inspect.

How the Built-In Parser Works

This converter ships with a lightweight YAML parser written in TypeScript that handles the subset of YAML used in roughly 95% of real-world config files. It tracks indentation depth to determine nesting, treats dash-prefixed lines as array items, auto-detects numbers and booleans by regex, and strips comment lines starting with #. Single-quoted and double-quoted strings are unwrapped, and the remaining scalars are treated as plain strings.

The parser deliberately does not support anchors, aliases, multi-document streams separated by ---, flow-style collections, or the various multi-line string indicators (| and > with chomp modifiers). If your file uses any of these features, the output may be wrong or the parser may refuse to continue. For full YAML 1.2 compliance, the js-yaml npm library is the standard JavaScript implementation, and PyYAML or ruamel.yaml are the standard choices in Python. For a browser-side conversion of a standard Kubernetes or Docker Compose file, the parser here is usually sufficient.

Sources

• YAML 1.2.2 Specification (yaml.org)
• YAML 1.1 Specification (yaml.org)
• JSON - Introducing JSON (json.org)
• GitHub Actions Workflow Syntax (GitHub Docs)
• Kubernetes Objects (kubernetes.io)
• PyYAML 6.0 Changelog (GitHub)