Skip to content

JSON YAML Converter

Convert JSON to YAML and YAML to JSON. Errors point to the line and column, and values like yes/no follow YAML 1.2. Nothing leaves your browser.

0 characters · 0 lines
Indent

Output is YAML 1.2. Strings a YAML 1.1 parser could read differently (yes, no, on, off, dates…) are quoted. YAML 1.2.2 spec (opens in a new tab)

0 characters · 0 lines

What you enter is processed only in this browser and is never sent to a server. How it works

Bidirectional conversion between a JSON object and YAML mapping preserving values a and b

How to use it

Pick a direction in the tabs at the top (JSON → YAML or YAML → JSON) and paste your data into the input box — the result appears right away. For JSON → YAML you can set the indent (2 or 4 spaces) and sort keys; for YAML → JSON you can set the indent (2 spaces, 4 spaces or a tab) and choose whether to wrap multiple documents in an array. Copy the result or download it as a .yaml or .json file. “Open file” loads a .json, .yaml or .yml file and picks the direction from its extension. Switching direction moves the result you just got into the input box, so you can convert it back. If the input isn’t valid, you’ll see the line and column of the problem and the code around it instead of a result.

The yaml library is downloaded on the first conversion.

How JSON and YAML relate

Both formats describe data with objects (mappings), arrays (sequences), strings, numbers, booleans and null. JSON marks structure with braces, brackets and double quotes; YAML mostly uses indentation, - and :, which makes it easier for people to read and edit. YAML 1.2, published in 2009, focused on making YAML a strict superset of JSON. That’s why valid JSON almost always reads as YAML too, and pasting JSON into YAML → JSON mode works. The reverse isn’t true: features JSON doesn’t have — comments, anchors, multiple documents — are dropped or expanded on the way to JSON.

What changes in conversion

  • Comments: JSON’s grammar (RFC 8259) has no place for comments, so they are all dropped when converting YAML to JSON. The YAML spec itself says comments are a presentation detail with no effect on the data. If you need to keep a note, write it as a key with a string value before converting, for example _comment: "staging port"; it ends up in the result as "_comment": "staging port". Not every # is a comment: a # with no space before it, as in http://a.com/#frag, and a # inside quotes stay part of the value. Input that contains nothing but comments gives the error “There is no YAML document to convert. Check whether the input only has comments.”
  • Anchors and aliases (&name, *name): the referenced value is copied in place. To block the “billion laughs” attack, where aliases multiply exponentially, conversion stops when aliases expand too many times (the yaml library’s default limit, maxAliasCount 100). A legitimate file that is no attack stops with the same error once a single anchor is referenced by 100 aliases (99 still convert; the size of the value doesn’t matter, and a << merge counts as one). When a value that contains aliases is itself aliased, the counts multiply and conversion stops sooner. If that happens, replace some of the aliases to that anchor with the actual values.
  • Merge keys (<<): not part of the YAML 1.2 schemas, but widely used in config files such as docker compose, so they’re expanded following the YAML 1.1 merge rules.
  • Multiple documents (---): in YAML → JSON, with “Wrap multiple documents (—) in an array” on (the default), each document becomes one element of a JSON array, and the result area shows the count, such as “3 documents”. Turn it off to convert only the first document; a warning tells you how many were left out. A lone document is never put in an array, whatever the setting. If the file ends with a bare --- and nothing after it, that counts as an empty document and adds a null at the end of the array — delete that line if you don’t want it. JSON → YAML always writes one document: a top-level array is not split up into --- documents.
  • Key order: both specs treat object keys as unordered, but this tool keeps the input order (number-like keys such as "2" aren’t moved to the front). Turn on “Sort keys” in JSON → YAML to sort every object’s keys by Unicode code unit.
  • Tags: tags this tool doesn’t know, such as !Ref, are removed and only the value is kept, with a warning. A tagged value such as !Ref 3 or !Ref true then comes out as a string, while tagged arrays and objects keep their structure and the values inside.
  • Values JSON lacks: .inf and .nan don’t exist in JSON, so they become null with a warning. YAML keys that are arrays or objects are written as JSON text.
  • Duplicate keys: the same key twice in one YAML mapping breaks the spec, so it’s reported as an error. The same key twice in a JSON object keeps only the last value, just like the browser’s JSON.parse, and shows a warning.

The Norway problem: yes, no, on, off

YAML 1.1 read y, yes, on, n, no and off (in several capitalizations) as booleans. So if you listed Norway’s country code NO without quotes, it became false — hence the name “Norway problem.” The YAML 1.2 core schema narrowed booleans down to true and false (and their capitalized forms, such as True and TRUE). This tool reads YAML that way, so NO, yes and off stay strings. There is no setting for reading YAML the 1.1 way, so rewrite every value you need as a boolean as true or false in the YAML itself. A mixed-case spelling such as tRue is a string, and so is a quoted value such as "true".

Some tools still follow YAML 1.1 rules, though. So in JSON → YAML output, strings that a 1.1 parser could read as something else get double quotes: boolean-like values (yes, no, on, off, y, n and so on), date-like values (2026-09-28), base-60 values (1:20), numbers with underscores (1_000) and the merge key <<. A quoted value is a string in both 1.1 and 1.2.

Big integers and number precision

JavaScript numbers are IEEE 754 doubles, so integers above 2^53 - 1 (9007199254740991, 16 digits) can have their last digits changed. This tool handles integers as BigInt in both directions, so large integers like 64-bit IDs come through digit for digit. In JSON → YAML, a trailing zero such as the one in 1.0 is kept as typed. In YAML → JSON, 1.0 turns into 1.

In YAML → JSON, an unquoted 01234 is read as an integer and becomes 1234; in the same way 1.10 becomes 1.1, 0x1F becomes 31 and 0o14 becomes 12. A postal code, a version number or any other code that has to survive exactly as typed needs quotes in the YAML, as in "01234" — JSON then receives it as a string. JSON → YAML writes number-like strings such as "01234" or "12345678901234567890" with quotes, so reading that YAML again still yields strings.

Decimals are handled as double-precision numbers in both directions, so a decimal with many significant digits such as 0.1234567890123456789 is rounded to the nearest double either way. Numbers in exponent notation change shape: in JSON → YAML 1e3 comes out as 1e+3, and in YAML → JSON 1e3 comes out as 1000. A value beyond the double range such as 1e400 becomes .inf in JSON → YAML. If the program that reads your JSON parses big integers as regular numbers, it can still lose precision there — when the exact value matters, it’s safer to keep it as a string at the source.

When you’d use it

  • Kubernetes manifests: YAML by convention, but JSON works too, and kubectl turns the manifest into JSON or another format when it calls the API. Handy for turning an API response (JSON) into a manifest (YAML), or the other way round.
  • GitHub Actions workflows: .yml or .yaml files in the .github/workflows folder, written in YAML. Useful when moving JSON config generated by a script into a workflow.
  • docker compose: the default file name is compose.yaml, and anchors, aliases and merge keys (<<) let you reuse service settings. Converting YAML to JSON shows the final values with every merge expanded.

Sources

Frequently asked questions

JSON with a trailing comma or single quotes gives an error in JSON → YAML. Is there a way to convert it?

Use YAML → JSON to read trailing commas, single quotes and unquoted keys as YAML. For example, {'a': 'x', 'b': [1, 2,],} becomes {"a": "x", "b": [1, 2]}; switch direction to turn that into YAML. Remove // and /* */ comments first: they are not YAML comments and may cause errors or incorrect keys. NaN and undefined are read as strings, not numeric or special values.

The JSON → YAML result has symbols such as |- or | in it. Did the conversion go wrong?

No. That is YAML's block notation for a string that contains line breaks. Enter {"msg": "line1\nline2"} and you get msg: |- with line1 and line2 indented on separate lines below it. The | means line breaks are kept as they are, and the - after it means the string has no line break at the end. A string that does end with one, such as "line1\nline2\n", is written with a | and no -. Convert the result back with YAML → JSON and you get the original "line1\nline2" again. In YAML you write yourself, using > in place of | gives a different result: put line1 and line2 on two lines under msg: > and the line break is folded into a space, giving "line1 line2\n". A value that simply runs over two lines with no symbol is joined the same way, into "line1 line2".

What does a YAML key with an empty value become in JSON?

It becomes null. Leave nothing after the colon, as in port:, and the result is "port": null; the values ~, null, Null and NULL all give null as well. If you need an empty string, write two quotes, port: "", which gives "port": "". nil and None are not null: they come out as the strings "nil" and "None". In JSON → YAML, null is written as null and an empty string as "". The strings "null" and "~" are written with quotes, so reading that YAML again doesn't turn them into null. An empty object and an empty array come out as {} and [].

How large can the input be?

Both directions accept up to 10MB of UTF-8 input, whether pasted or loaded from a file. For example, 3.5 million Hangul characters take 10,500,000 bytes and exceed the limit. The limit applies to input, not output size; split larger data before converting.

My YAML is indented with tabs and I get an error. What should I do?

YAML doesn't accept tab characters as indentation. A tab at the start of a line therefore stops the conversion, and the error points to the tab's line and column with the message "YAML doesn't allow tabs for indentation. Use spaces instead." Replace the tabs at the start of that line with spaces and the conversion goes through. A tab between key: and its value, or inside quotes, is not a problem. The "Tab" choice under "Indent" only sets how the JSON produced by YAML → JSON is indented; it has nothing to do with the YAML you paste. JSON may be indented with tabs, so JSON → YAML converts such input as usual, and the YAML it writes is indented with 2 or 4 spaces.

Open-source software used: yaml (ISC)

Last updated: