JSON to YAML Converter

How to use it

1. Pick a direction, JSON to YAML or YAML to JSON.
2. Paste your text into the input box.
3. The result appears as you type. You can also press Convert.
4. Switch the output between Text and Highlighted if colour helps you scan it.
5. Press Copy output to take the result.

If the input is broken, the red box under the buttons shows the parser's message, with the line and column. The output clears at the same time, so you never copy half a result by mistake.

The conversion runs inside the page. Your text is parsed by JavaScript in your own browser tab and is not posted to a server to be converted.

What is doing the work

Both directions go through js-yaml 3.14.2, a vendored copy of a well-used library, rather than a parser written by hand. JSON to YAML runs JSON.parse and dumps the result. YAML to JSON loads the document and prints it back with two-space indentation.

That detail matters more than it sounds. A YAML parser does not simply read your text. It guesses what your unquoted values mean, and the guessing rules changed between YAML versions.

The types YAML guesses for you

YAML 1.1 had a famously wide idea of what counts as a boolean. Itsbool type resolves y, Y, yes, no, on and off, in several capitalisations, to true or false. That is the root of the Norway problem: the ISO country code for Norway is NO, so country: NO quietly becomes false in any parser still following 1.1, PyYAML included.

The YAML 1.2core schemacut the list down to true, True, TRUE, false, False and FALSE. This converter follows the shorter list. Pastecountry: NO and you get "country": "NO" back, a plain string. The same goes for yes, no, on, off, y and n.

Numbers are messier, because js-yaml 3 kept two habits from YAML 1.1 that still catch people out. Base-60 integers are the sharp one. The YAML 1.1int type allows colon-separated digits to form a single number, which the spec calls convenient for time and angle values. An unquoted clock time is therefore arithmetic, not text. Leading zeros trigger the second habit, octal.

750 is 12 times 60 plus 30. 45000 is twelve and a half hours counted in seconds. 493 is octal 755 in decimal, the Unix permission bits you meant. But 08 survives as a string, because 8 is not a valid octal digit and the pattern no longer matches.

Two more worth knowing. The YAML values .inf and .nan are legal, and JSON has no way to write either, so both arrive in the output as null. A bare date resolves to a timestamp and comes back as a full ISO string with a time and a Z bolted on.

The fix in every one of these cases is a pair of quotes. Write build: "12:30" and it stays the text 12:30.

The JSON to YAML direction rarely bites

Going from JSON, the library quotes anything that would be misread coming back. The string "yes" is written as'yes'. "NO" is written as 'NO'. "12:30" and "1.20" pick up quotes too. Feed that YAML straight back in and every value returns exactly as it started, so the risk sits almost entirely on YAML you typed yourself or inherited from someone else's repo.

Key order survives as well. An object with the keys zebra, apple and middle keeps that order in the YAML output, which keeps a diff against the original readable.

Strings past roughly 80 characters get folded onto a second line behind a >- marker. That folding reads back as one line with the value unchanged.

One document at a time

A YAML file can hold several documents in one stream, separated by a line of three dashes. Kubernetes manifests do this constantly. The converter loads a single document, so a stream returns "expected a single document in the stream, but found more" instead of silently converting the first part and dropping the rest. Split the file and run each document through separately.

Duplicate keys split the two directions apart. RFC 8259 permits a JSON object to carry the same name twice and leaves the outcome to the parser, and JSON.parse keeps the last one it sees. js-yaml refuses outright and reports "duplicated mapping key" with a line number. A YAML file with a repeated key therefore fails here, even though its JSON twin would sail through.

Where each format earns its place

JSON is the wire format. APIs return it, every language reads it, and it carries no comments and no argument about types. YAML is the config format, which is why Docker Compose, Kubernetes, GitHub Actions and Ansible all read it: indentation is kinder on the eye than four nested levels of braces. Most people land here going one of two ways. Either they have an API response and want a readable config file out of it, or they have a config file and need JSON for a tool that will accept nothing else.

Frequently asked questions

Related: JSON Formatter