Online Tool Store
YAML to JSON Converter
Converts YAML to JSON and back with js-yaml, handling multi-document files. Warns when unquoted values are reinterpreted — dropped leading zeros, lost version digits, oversized integers, the Norway problem — and lets you switch between YAML 1.2 and 1.1 schemas.
🔒 This tool runs entirely in your browser. Your files are never uploaded to a server.
Parsed in this page with js-yaml — nothing is uploaded, which matters because YAML files are so often deployment configuration. A multi-document YAML file becomes a JSON array, since JSON has no concept of multiple documents.
How to use it
- Paste YAML, or open a file — the sample contains several traps on purpose.
- Read any amber warnings. The conversion succeeded; the warnings are about meaning, not syntax.
- Switch the schema to see how much of YAML's behaviour depends on that choice.
- Use the JSON → YAML tab to go the other way.
Conversion is easy; not corrupting your data is not
Turning YAML into JSON is a single function call, which is why there are so many converters. The problem is that YAML decides what your unquoted values mean, and several of those decisions quietly destroy information. These all happen with the modern YAML 1.2 core schema — they are not legacy behaviour:
zip: 01234 → 1234 leading zero gone
version: 1.20 → 1.2 trailing zero gone
mode: 0o755 → 493 octal, now decimal
id: 12345678901234567890 → …4567000 past the safe integer limit
The output in every case is valid JSON that looks entirely reasonable, which is precisely why this is dangerous — nothing fails, and the wrong value travels onwards. So this tool reads your source text alongside the parsed result and tells you when a value has been reinterpreted. Quoting is the fix in all four cases.
The integer limit deserves a note: JavaScript numbers are exact only up to 9007199254740991. Just past it, 9007199254740993 becomes 9007199254740992 — a silent change in the final digit. Long numeric IDs from a database should be quoted and treated as strings, since arithmetic on them is not something you want anyway.
The schema changes the answer
This is the single most confusing thing about YAML, and it is worth seeing rather than reading about. The same three lines produce different data depending on which version of the specification is applied:
YAML 1.2 core YAML 1.1
country: no "no" false
time: 22:22 "22:22" 1342
enabled: yes "yes" true
The Norway problem is the first row: a country code of no
becoming false under YAML 1.1. The second is sexagesimal notation —
base 60 — where 22:22 is read as 22 × 60 + 22 = 1342. Both are gone in YAML 1.2, which is why it is the default here.
The most striking demonstration is that 1.1 applies this to keys too. A field named
y becomes the boolean true,
and lands in your JSON as the key "true". If your file might be read
by an older parser, quote these values even though 1.2 does not require it.
Things JSON simply cannot express
Some YAML features have no JSON equivalent, so the conversion has to make a decision:
Multiple documents become a JSON array, one element each. This is what you
want for Kubernetes manifests separated by ---.
Anchors and aliases are expanded, because JSON has no references — so a
value reused in five places appears five times, and the file gets larger.
Comments are discarded, since JSON has none; that is usually the most
valuable thing lost in the conversion, so keep the YAML as your source of truth.
Merge keys are the awkward case: they are not in the 1.2 core schema, so
<< comes through as a literal key until you enable the merge
tag with the checkbox — which is preferable to dropping to the 1.1 schema, since it leaves the scalar rules alone.
Going the other way is safer
JSON to YAML has far fewer traps, because JSON says exactly what it means and the YAML writer is deliberately cautious. It
quotes anything that could be misread — a string of 01234 comes back
as '01234', and even a key named
n is quoted in case a 1.1 parser reads it as a boolean.
Those quotes can look unnecessary. They are not — they are what makes the file survive a round trip through a parser that is less careful than this one.
FAQ
Why does my postcode turn into a different number?
Because YAML reads an unquoted 01234 as a number, and numbers do not have leading zeros — so it becomes 1234. The same thing happens to zero-padded account numbers and IDs. Quoting it as "01234" fixes it completely. This tool detects the pattern in your input and warns you, because the output looks perfectly valid and the damage is silent.
Why did version 1.20 become 1.2?
Same cause, opposite end of the number. Unquoted, 1.20 is a decimal, and 1.20 equals 1.2, so the trailing zero has nowhere to live. Version strings are the usual casualty and the result compares as a different version to anything downstream. Quote it.
What is the Norway problem?
In YAML 1.1, the unquoted words no, yes, on, off, y and n are booleans — so a country field containing no becomes false. It bites hardest with country codes, hence the name. Modern YAML 1.2 fixed this, and with the 1.2 core schema selected here those values stay as text. Switch the schema to 1.1 and you can watch them turn into booleans, including a key named y becoming true.
Which schema should I choose?
YAML 1.2 core, the default, unless you know otherwise — it is what modern tooling uses and it has the fewest surprises. Choose 1.1 only to reproduce the behaviour of an older parser; if all you need is merge keys, use the checkbox instead, which adds that one tag without the 1.1 scalar rules. The failsafe schema leaves absolutely everything as a string, which is occasionally exactly what you want when you are trying to see what a file really says.
Why is my merge key not merging?
Merge keys are not part of the YAML 1.2 core schema by default, so << arrives as an ordinary key whose value is the anchored map — almost certainly not what you meant. Tick "Resolve << merge keys" and the merge works while keeping every other 1.2 rule. That is better than switching to the 1.1 schema, which resolves merges but also turns no into false and a key named y into true. Plain anchors and aliases without a merge work under any schema, and are expanded in the output because JSON has no way to express a reference.
What happens to a file with several documents?
It becomes a JSON array, one element per document, because JSON has no concept of multiple documents in one file. Kubernetes manifests separated by --- are the common case. A single-document file converts to a plain object rather than a one-element array.
Is my file uploaded?
No. Parsing happens in your browser using js-yaml. That matters more than usual for YAML, since these files are so often deployment configuration containing hostnames, bucket names and occasionally secrets.
How we compare
| Feature | Online Tool Store | Other online converters | yq on the command line |
|---|---|---|---|
| File never leaves your device | ✓ | ✗ | ✓ |
| Warns about silent value corruption | ✓ | ✗ | ✗ |
| Selectable YAML schema | ✓ | ✗ | Limited |
| Handles multi-document files | ✓ | Often not | ✓ |
| Converts both directions | ✓ | Usually one | ✓ |
| Preserves comments | ✗ | ✗ | Sometimes |
| Queries and transforms structure | ✗ | ✗ | ✓ |
Use this when you want to know what your YAML actually means, not just to reshape it — the warnings are the reason to prefer it
over a converter that only reformats. For querying, filtering or editing YAML in a pipeline,
yq is the right tool and can keep your comments.