YAML ⇄ JSON Converter

Convert one YAML document to JSON or back with safe JSON-compatible types, indentation and downloads.

This tool runs entirely in your browser. Your data is never uploaded, never stored, and never leaves your device.

Converts one YAML document to JSON or JSON back to YAML using JSON-compatible typing, so date-looking values stay strings instead of silently becoming timestamps.

How to use it

1Switch between YAML → JSON and JSON → YAML with the two buttons above the input.
2Paste a single document. Multi-document YAML separated by --- is refused with a clear instruction to split it.
3Choose two- or four-space indentation, then copy, download or swap the result into the reverse direction.

Example

Input: debug: no port: 8080
Output: { "debug": "no", "port": 8080 }

no stays the string "no". This parser follows YAML 1.2, where only true and false are booleans — YAML 1.1 tools would have turned it into false, and that mismatch is a long-standing source of config bugs.

What happens to your data

This tool runs entirely in your browser. Your input is never uploaded to a server, never stored, and never logged. YAML is where deployment configs tend to keep their secrets, so parsing is done locally by the js-yaml library bundled into the page.

Last updated September 2026

Someone sends you a config as JSON and the pipeline that has to read it wants YAML. Or a colleague pastes forty lines of docker-compose into a ticket and you need it as JSON so a script can pick two fields out of it. Both formats describe the same shapes — maps, lists, strings, numbers, booleans and null — so the translation is mechanical right up to the point where it is not.

The thing to settle before you paste anything is which direction is the lossy one. JSON to YAML is the safe way round: everything JSON can express, YAML can hold. The other way is not, because YAML carries several things JSON has nowhere to put — comments above all, along with anchors and aliases, explicit tags, and the difference between a folded block and a literal one. Convert a Kubernetes manifest to JSON and every note your team left in it disappears.

That leads to the common mistake, which is treating a round trip as reversible. YAML in, JSON out, back to YAML gives you a file that means the same thing to a machine and is unrecognisable to whoever maintains it. Convert a copy; keep the original as the one you edit.

The second trap is quoting. YAML guesses types from how a value is written, so a version number or a leading zero can arrive as something you did not intend. Put single quotes round anything that has to stay text before converting, rather than repairing the JSON afterwards.

How it works

Toolvore converts one document at a time in the page with js-yaml and its JSON-compatible schema. That schema deliberately keeps timestamp-looking text, capitalised booleans, leading-zero values, .inf and .nan as strings instead of silently inventing JavaScript dates, booleans or non-JSON numbers. Comments, blank lines, quoting style and block-scalar style still disappear because the parsed value carries data rather than presentation. Anchors resolve to repeated values, and aliases can make the output larger. Genuine JSON numbers still use JavaScript double precision, so quote a long identifier if every digit matters. Choose two- or four-space output, then copy, download or Swap the result; inputs over two million characters and YAML streams containing more than one document are refused explicitly.

Common use cases

Turning a docker-compose file into JSON for a script to read
Rewriting a JSON settings block as YAML for a CI pipeline
Checking whether a hand-edited manifest parses at all before committing it
Finding the line and column of an indentation error a build log only hinted at
Seeing what a value like 08 or 3.10 actually becomes once parsed
Expanding anchors and aliases to see what a config resolves to
Reformatting a minified JSON payload pasted out of a log

Frequently asked questions

Is JSON valid YAML, and can I paste JSON into the YAML side?＋

YAML 1.2 is a superset of JSON, and this parser behaves that way: braces and brackets are YAML written in flow style. Paste a JSON document into the YAML to JSON direction and it comes back at the two- or four-space indentation you selected. The reverse does not hold — a YAML file using indentation instead of braces is not JSON, and pasting one into the JSON to YAML direction produces a parse error.

Which values do I need to put in quotes in YAML?＋

Quote anything whose spelling matters more than its numeric value. With the JSON-compatible schema here, only lowercase true and false become booleans; True, FALSE, yes, no, on and off remain strings. Leading-zero values such as 0755 also remain strings. A genuine decimal such as 3.10 is still a number and serialises as 3.1, and a long unquoted integer can exceed JavaScript's exact range. Quoting versions and identifiers is the portable choice when another YAML parser may use different rules.

What happens to the comments in my YAML file?＋

They cannot survive, because JSON has no comment syntax. The parser reads them and discards them, and nothing in the output marks where they were — which in most YAML files is where the reasons live, so it is often the majority of the human value in the document. The trap works the other way too: a config written in JSON with C-style comments, sometimes called JSONC, is not valid JSON and the JSON to YAML direction refuses it at the first slash. Strip those comments, or bring the file in through the YAML side, which accepts hash comments happily.

What happens to anchors, aliases and merge keys?＋

Anchors and aliases are resolved during parsing, not preserved. A map defined once and referred to in five places is written out five separate times, so the JSON is correct but longer, and the shared definition you were relying on for maintenance is gone. Merge keys deserve their own warning: the merge type is not part of the YAML 1.2 core set, so a line reading << followed by an alias is not merged into the surrounding map — the key << survives literally, holding the referenced map as its value. Check the output before assuming your defaults were applied.

Why does my CloudFormation or pipeline template report an unknown tag?＋

Because tags outside the core set are not recognised, and the parser stops rather than guessing. A template containing !Ref or !GetAtt, or a document using the binary type, produces an unknown scalar tag message naming the line and column of the offending tag. That is the honest behaviour for a converter that does not know your schema: a tag is an instruction to build a value of some application-specific type, and there is no general JSON equivalent for one. To convert such a file, replace the tags with their long form first, or convert only the parts that avoid them.

Can YAML use tabs, and why does my hand-edited file keep breaking?＋

Never for indentation — tab characters there are rejected outright, with the line and column named, and it is a common reason a hand-edited file fails. Set your editor to insert spaces for YAML and it stops happening. The worse case is the indentation mistake that does not fail: misalign the items of a list and they can be read as one plain scalar spread over several lines, so a two-item list arrives as a single joined string. Nothing errors, the output is quietly wrong, which is why it is worth reading the JSON rather than treating no red text as success.

Is my config file uploaded anywhere when I convert it?＋

Nothing is sent anywhere. What you type lives in the page as component state, the conversion runs in a memo that recomputes as you type, and the parsing is done by a library bundled into the JavaScript your browser already loaded — no upload, no request, no server route behind it. That is the reason to prefer a local converter for this format in particular: YAML is where deployment configs keep database passwords, API keys and connection strings, and pasting one into a remote service hands those over. Closing the tab is the whole of the cleanup.

Do large numbers and IDs survive the conversion intact?＋

Not when an unquoted value is parsed as a number beyond JavaScript's safe integer range. A twenty-digit identifier can come back rounded, so identifiers should be quoted as strings. The JSON-compatible schema used here is intentionally conservative: leading-zero values, .inf and .nan stay strings rather than being coerced. That avoids several silent changes, but it cannot restore digits already represented as an imprecise JSON number.