YAML to JSON converter

1. Paste your YAML. Drop it into the left-hand box, or click Upload file to load a.yaml or .yml file straight from disk.
2. Read the JSON output. The right-hand box updates as you type — no button to click, no page reload.
3. Fix errors if flagged. If the YAML has a syntax problem, a red alert shows the exact line and column so you can jump straight to it in your editor.
4. Copy or download. Use Copy output to grab the JSON, or Download to save it as a .json file.

Need to go the other way? Flip the Direction toggle to JSON → YAML, or click Swap direction after a conversion to instantly reverse it and edit the result further.

YAML and JSON both describe the same thing — structured data made of objects, arrays, strings, numbers, booleans, and null — but they look and behave very differently on the page. Here's how they compare:

In short: YAML is optimized for humans writing and reviewing config by hand, while JSON is optimized for machines exchanging data quickly and unambiguously. That's why config files (Kubernetes, GitHub Actions, Docker Compose) tend to be YAML, while APIs and data interchange almost always use JSON.

Because YAML uses whitespace instead of brackets to define structure, indentation mistakes are the most common source of broken configs. Watch out for these:

• Tabs are illegal. The YAML spec forbids tab characters for indentation — only spaces are allowed. Most editors insert tabs by default, which silently produces a parse error.
• Inconsistent indent width breaks nesting. Mixing 2-space and 4-space indents in the same file (or the same block) makes YAML misread which level a key belongs to.
• List items need to line up with their key, not be indented an extra level unless your style intentionally nests them — items: followed by - a at the same indent asitems or one level deeper are both valid, but mixing styles within one list is not.
• A trailing colon with no value (key: with nothing after it) is parsed as null, not an empty string — a frequent source of "why is this field null" bugs.
• Unquoted special characters like :, #, {, [, or a leading */& can be misread as YAML syntax rather than literal text — wrap the value in quotes if it contains them.
• Copy-pasting from Slack or a PDF often introduces smart quotes or non-breaking spaces that look identical to normal characters but fail to parse — retype suspicious lines if an error persists.

YAML has a well-known quirk nicknamed the "Norway problem." The YAML 1.1 specification treats a set of bare, unquoted words as booleans — not just true/false, but also yes, no, on, off, y, and n (in various cases). The country code for Norway is NO, so a YAML file listing country codes like:

countries:
  - US
  - FR
  - NO

silently converts NO into the boolean false when parsed, turning "Norway" into "false" in your data. This has caused real production bugs — a well-known GitHub issue on the Norway problem is one of the most-referenced YAML parser bugs of all time.

How to avoid it: always quote ambiguous bare strings — "NO", "YES", "ON", "OFF" — especially country codes, abbreviations, and version-like strings. Modern YAML 1.2 parsers (including the js-yaml library this tool uses in its default schema) narrowed the auto-boolean list down to just true/false, which fixes the Norway case but still catches people off guard when their file was written for a stricter 1.1 parser like PyYAML's default loader. Converting to JSON with this tool is a fast way to check exactly how your YAML values get typed — if a country code shows up as true or false in the JSON output, quote it in the source YAML.

• Use YAML for configuration files that humans write and maintain by hand: Kubernetes manifests, Docker Compose files, GitHub Actions / GitLab CI pipelines, Ansible playbooks, and application settings where comments and readability matter.
• Use JSON for anything machine-to-machine: REST API request and response bodies,package.json-style tooling config, data interchange between services, and anywhere a strict, unambiguous grammar matters more than human readability.
• Use JSON when you need speed. JSON parses faster and has a much smaller spec surface, so it's the better choice for high-throughput systems or large data payloads.
• Use YAML when you need comments or references. JSON has no comment syntax and no way to reuse a block of config via anchors — if either matters, YAML is the only option of the two.
• When in doubt for public APIs, use JSON. It's supported natively by virtually every language and HTTP client, with no ambiguity about how a given value will be typed.

YAML is the de facto configuration language of modern infrastructure, which is exactly why a fast, accurate YAML ↔ JSON converter is useful day to day:

• Kubernetes manifests (Deployments, Services, ConfigMaps, Secrets) are written in YAML, but the Kubernetes API server internally works with JSON — converting a manifest to JSON is a quick way to see exactly what fields and types kubectl apply will actually send.
• Helm charts render YAML templates that frequently need to be debugged by comparing the rendered output against the JSON the API expects.
• GitHub Actions and GitLab CI pipelines are defined in YAML, and matrix or reusable workflow inputs are often easier to validate once flattened to JSON.
• Terraform and OpenAPI tooling frequently accepts either format — converting lets you move a spec from a human-edited YAML source into the JSON some tools expect.
• Debugging "why didn't my config apply" issues is much faster in JSON, where every key and type is unambiguous and indentation mistakes can't hide a bug.

Because indentation and boolean auto-typing (see the Norway problem above) are the two biggest sources of silent YAML bugs, converting to JSON before you deploy is a cheap sanity check that catches both.

Yes. Conversion runs entirely client-side using the js-yaml library and your browser's built-in JSON parser — your YAML and JSON never leave your device or touch a server. That makes it safe to paste Kubernetes secrets, internal service configs, or any other sensitive data. The tool also works offline once the page has loaded, with no account, no rate limit, and no watermark on the output.