YAML to JSON Converter - Convert YAML to JSON Online

Q: What is the "Norway problem"?

In YAML 1.1 the words yes, no, on, off, y, and n are booleans. So country: NO — Norway's ISO country code — parses as false, and a country list quietly loses an entry. YAML 1.2 narrowed booleans to true/false only, so this converter keeps "NO" as a string. The catch is that plenty of parsers still follow 1.1: PyYAML, Ruby's Psych, and older Go YAML libraries all give you false. Quote the value (country: "NO") and every parser agrees.

Q: Why did my version number change?

Because unquoted 1.20 is a float, and the float 1.20 is the number 1.2 — the trailing zero has no meaning in arithmetic. So version: 1.20 converts to "version": 1.2 and your v1.20 release now looks like v1.2. Same class of bug bites long digit strings: iccid: 8944500102030405060 exceeds JavaScript's safe integer range and comes out as 8944500102030405000. Anything that is an identifier rather than a quantity should be quoted in the YAML.

Q: What happens to anchors and aliases?

They are expanded, not preserved. An anchor (&defaults) plus alias (*defaults) is YAML's way of writing a block once and reusing it; JSON has no equivalent, so each reference is replaced by a full copy of the block. A file with one shared block and five aliases becomes JSON with five duplicated objects. That is correct — but if you convert back to YAML afterwards, the sharing is gone and the file will be noticeably longer.

Q: Can it handle multi-document YAML?

A file split by --- holds several documents; this converter reads the first one, because JSON has no notion of a document stream. If you need all of them, split the file and convert each part, or wrap the documents in a single top-level list before converting.

YAML Input

JSON Output

What is a YAML to JSON Converter?

YAML is what humans write and JSON is what programs read. Kubernetes manifests, GitHub Actions workflows, Docker Compose files, Ansible playbooks, OpenAPI specs — all YAML, because indentation and comments are easier to live with than braces. But the moment you want to run jq over it, validate it against a JSON Schema, drop it into a request body, or diff it in a tool that only speaks JSON, you need the other form. That is what this page does: paste YAML on the left, get formatted JSON on the right as you type.

The parsing runs on js-yaml, which implements the YAML 1.2 specification, and the output is serialised with JSON.stringify at two-space indentation so it satisfies RFC 8259. Everything happens in your browser tab. Your cluster secrets, connection strings, and subscriber data never touch a server — there is no upload, no round-trip, no logging.

One thing to know before you convert anything: comments do not survive. JSON has no comment syntax, so every # line in your YAML is gone the moment it becomes JSON, and it cannot be recovered by converting back. If those comments are the only documentation for a production config, keep the YAML file as the source of truth and treat the JSON as a derived artifact.

How to Convert YAML to JSON

Paste Your YAML – Drop a manifest, playbook, or .yml config into the left panel. Multi-document files (the ones separated by ---) convert their first document; split them if you need all of them.
Watch the JSON Appear – There is no Convert button. A 300 ms debounce re-parses after you stop typing, so the right panel always shows the JSON for what is currently in the editor.
Read the Error Line – If the YAML is broken, the output panel names the line and column — for example Invalid YAML (line 7, column 3): bad indentation of a mapping entry. Count to that line in the left editor and the problem is almost always right there or one line above.
Check How Values Were Typed – YAML infers types from unquoted text. Scan the JSON for anything that came out as a number or boolean when you meant a string — version numbers and long identifiers are the usual casualties.
Copy or Download – Copy puts the JSON on your clipboard; Download saves it as converted.json, ready to feed to a schema validator or an API client.

Pro Tip: If a value must stay a string, quote it in the YAML before converting. version: 1.20 becomes the number 1.2 and you have silently lost a release; version: "1.20" stays "1.20". The same rule saves ICCIDs, IMSIs, phone numbers, ZIP codes, and anything else that is digits but not arithmetic.

Example

A short subscriber profile. Note what happens on the way across: the # provisioning defaults comment disappears (JSON has no comments), roaming: true becomes a real boolean, rsrp: -92 becomes a number, and the quoted iccid stays a string — which is exactly what you want for a 19-digit identifier.

YAML → JSON Convert

subscriber.yamlYAML

# provisioning defaults
subscriberId: SUB-1001
msisdn: "447700900142"
iccid: "8944500102030405060"
plan: Unlimited 5G
roaming: true
rsrp: -92
apns:
  - name: internet
    qci: 9

subscriber.jsonJSON

{
  "subscriberId": "SUB-1001",
  "msisdn": "447700900142",
  "iccid": "8944500102030405060",
  "plan": "Unlimited 5G",
  "roaming": true,
  "rsrp": -92,
  "apns": [
    { "name": "internet", "qci": 9 }
  ]
}

Common Use Cases

Querying Kubernetes and CI Files with jq

kubectl can hand you JSON, but the manifest in your repo is YAML, and half the time the thing you want to inspect is the file on disk rather than the live object. Converting it here lets you run a jq expression against it, pipe it into a script, or paste it into a tool that only accepts JSON. The Kubernetes object documentation explains what the fields mean once you have them in front of you.

Validating a Config Against JSON Schema

Most schema tooling — JSON Schema validators, OpenAPI linters, IDE plugins — validates JSON. Convert the YAML first and you can check a deployment config or an API spec against its schema before it reaches a pipeline that fails at 2 a.m.

Turning a Hand-Written Fixture into Test Data

Writing test fixtures in YAML is far pleasanter than writing them in JSON: no trailing-comma errors, no quote soup, and you can comment each case. Author the fixture in YAML, convert it here, and commit the JSON your test harness actually loads.

Key Features

Real-Time Conversion – JSON updates as you type; a short debounce keeps it responsive on large manifests.
Line and Column in Every Error – YAML errors report where they happened, not just that something went wrong.
Tab Detection – Indent with a tab and you get a message saying so, instead of a cryptic "bad indentation" complaint three lines later.
YAML 1.2 Semantics – Parsed with js-yaml's default core schema, the same behaviour modern YAML tooling expects.
Privacy First – Everything runs in your browser. No upload, no server, no logs.

Frequently Asked Questions

Do comments survive the conversion?

No, and nothing can change that — JSON has no comment syntax. Every # ... line is dropped when the YAML becomes JSON, and converting the JSON back to YAML will not bring them back. Keep the YAML as the file you edit and the JSON as the file you generate. If a comment carries information a program needs, promote it to a real key such as _note: "leave qci at 9 until the core upgrade".

What is the "Norway problem"?

In YAML 1.1 the words yes, no, on, off, y, and n are booleans. So country: NO — Norway's ISO country code — parses as false, and a country list quietly loses an entry. YAML 1.2 narrowed booleans to true/false only, so this converter keeps "NO" as a string. The catch is that plenty of parsers still follow 1.1: PyYAML, Ruby's Psych, and older Go YAML libraries all give you false. Quote the value (country: "NO") and every parser agrees.

Why did my version number change?

Because unquoted 1.20 is a float, and the float 1.20 is the number 1.2 — the trailing zero has no meaning in arithmetic. So version: 1.20 converts to "version": 1.2 and your v1.20 release now looks like v1.2. Same class of bug bites long digit strings: iccid: 8944500102030405060 exceeds JavaScript's safe integer range and comes out as 8944500102030405000. Anything that is an identifier rather than a quantity should be quoted in the YAML.

Why does my file fail with a tab error?

YAML forbids tab characters in indentation — full stop, it is in the spec, and every conformant parser rejects them. An editor configured to insert a hard tab will produce a file that looks perfectly aligned and refuses to parse. This page detects a leading tab and tells you which line it is on. Set your editor to expand tabs to spaces for .yaml and .yml; two spaces per level is the community convention.

What happens to anchors and aliases?

They are expanded, not preserved. An anchor (&defaults) plus alias (*defaults) is YAML's way of writing a block once and reusing it; JSON has no equivalent, so each reference is replaced by a full copy of the block. A file with one shared block and five aliases becomes JSON with five duplicated objects. That is correct — but if you convert back to YAML afterwards, the sharing is gone and the file will be noticeably longer.

Is valid JSON also valid YAML?

Yes. YAML 1.2 is a strict superset of JSON, so you can paste a JSON document into the left panel and it will parse fine — it just comes back reformatted. Handy when you are not sure which format a snippet is in, and the reason many tools accept a single --values flag for both.

Can it handle multi-document YAML?

A file split by --- holds several documents; this converter reads the first one, because JSON has no notion of a document stream. If you need all of them, split the file and convert each part, or wrap the documents in a single top-level list before converting.

Is my data safe?

Yes. Parsing runs entirely in your browser with js-yaml. Nothing is uploaded, cached, or logged — which matters, because YAML files are exactly where API keys and database passwords tend to live.

Related Tools

JSON to YAML – The reverse trip — turn a JSON payload into readable YAML.
JSON Formatter – Re-indent or tidy the converted JSON before you commit it.
JSON Validator – Confirm the output parses cleanly before wiring it into your app.
XML to JSON – Same idea for the XML configs and SOAP payloads you still have to deal with.
JSON to Table – Preview the converted JSON as a table to sanity-check the shape.

Useful Resources

YAML 1.2.2 Specification – The official spec — the place to settle arguments about types and indentation.
js-yaml – The parser behind this page, including its schema and safety notes.
RFC 8259 – The IETF JSON specification — what the output conforms to.
YAML Multiline Strings – A visual cheatsheet for the difference between the pipe and folded block styles.
JSON Schema – Validate the converted JSON against a schema before it reaches production.
JSON.org – Original JSON spec with railroad-style grammar diagrams.

YAML to JSON