Or drag and drop a file onto this box. Files up to 100 MB.
JSON to YAML Converter
Convert JSON to YAML in your browser with safe quoting, multi-line blocks, sorted keys and flow style.
A JSON to YAML converter rewrites JSON as YAML, the indentation-based format used by configuration files, CI pipelines, Kubernetes manifests and many developer tools. Every JSON document is already close to valid YAML, but writing it out correctly is harder than it looks: a plain string such as NO, 1.0 or 2026-10-20 means something different in YAML than it did in JSON. This page quotes whatever needs quoting, keeps numbers exactly as typed, and lets you choose the indentation, the quoting style, block or flow style, key order, line width, null spelling, multi-line handling and multiple documents.
How do I convert JSON to YAML?
Paste your JSON, choose a .json file or load the sample, and the YAML appears next to it with its line count and size. Adjust an option to update it, then copy it or download a .yaml file.
- Bring the JSON in: by pasting, dropping a file onto the upload area, or coming from the JSON Formatter. A syntax error is reported with the line and column where it was found.
- Pick a layout: two or four spaces, block style or flow style, and whether keys are sorted.
- Pick the quoting: only where it is needed, or always double or always single quotes.
- Check the notices: anything the converter had to adjust is listed above the output.
To read YAML back into JSON, the YAML to JSON converter does the opposite, and the JSON to XML converter writes the same data for XML-based systems.
Which strings does the converter quote, and why?
Any string that a YAML reader could take for a different type, or could not read as a plain value at all. Quoting is what makes the YAML mean the same thing as the JSON.
| String | Why plain text would be wrong |
|---|---|
yes, no, on, off, y, n in any letter case | YAML 1.1 reads them as booleans, which is the Norway problem: the country code NO becomes false |
true, false, null, ~ | They are the YAML booleans and null |
1.0, 1e3, 0x1F, 0o7, 1_000, .5, .inf, .nan | They are numbers in YAML, in several notations |
2026-10-20 and timestamps | Many readers turn them into dates |
| The empty string | An empty value is null |
| Text with spaces at the start or end, or with a tab | The spaces would be dropped |
a: b, a #b and text ending in a colon | A colon and a space starts a mapping, and a space and a hash starts a comment |
Text starting with - ? : , [ ] { } # & * ! | > ' " % @ or a backtick | These characters have a meaning at the start of a value |
| Text with control characters, or a line separator | It needs escapes, so it is written in double quotes |
Keys follow the same rules, so the key yes is quoted and so is 1. In flow style more characters are special, so strings with commas, brackets, braces or colons are quoted there as well.
Worked example: the quoting traps
This configuration contains six strings that are easy to get wrong, plus a number, a boolean and a null.
JSON input
{
"country": "NO",
"flag": "yes",
"version": "1.0",
"released": "2026-10-20",
"empty": "",
"padded": " a ",
"ratio": 0.5,
"enabled": true,
"nothing": null,
"port": 8080
}
YAML output
country: 'NO' flag: 'yes' version: '1.0' released: '2026-10-20' empty: '' padded: ' a ' ratio: 0.5 enabled: true nothing: null port: 8080
Without the quotes, the same lines would be loaded as a boolean, two numbers-like values, a date and a null:
The same lines with the quotes removed (do not use)
country: NO flag: yes version: 1.0 released: 2026-10-20 empty: padded: a ratio: 0.5 enabled: true nothing: null port: 8080
NO, yes, 1.0 and the date all change type, and the empty value becomes null. The quoted output keeps every one of them a string, and the port, the ratio, the boolean and the null stay what they were.
Worked example: multi-line strings
A string with line breaks is easier to read as a literal block, which starts with a pipe and keeps every line break. The sign after the pipe tells YAML how to treat the final line break: a minus removes it, no sign keeps exactly one, and a plus keeps all of them.
JSON input
{
"motd": "Welcome\nto the service\n",
"sql": "SELECT 1\nFROM t",
"note": "a\tb"
}
Multi-line strings as | blocks (default)
motd: | Welcome to the service sql: |- SELECT 1 FROM t note: "a\tb"
The text with a tab is written in double quotes with a tab escape, because a literal block cannot hold tabs safely. When Multi-line strings as | blocks is off, every line break is an escape in a quoted string instead:
Multi-line strings as | blocks off
motd: "Welcome\nto the service\n" sql: "SELECT 1\nFROM t" note: "a\tb"
Worked example: indentation, key order and flow style
The same small document in block style, then with four spaces and sorted keys, then in flow style. The key y is quoted in every form, because YAML 1.1 treats a plain y as true.
JSON input
{
"b": {
"z": 1,
"y": [
1,
2
]
},
"a": "x"
}
Block style, 2 spaces (default)
b:
z: 1
'y':
- 1
- 2
a: x
4 spaces, sort keys
a: x
b:
'y':
- 1
- 2
z: 1
Flow style
{b: {z: 1, 'y': [1, 2]}, a: x}
Sort keys orders every object alphabetically, which helps when the YAML is kept in version control. Flow style writes the entire document on one line using braces and brackets, so it is compact but harder to read.
Quoting styles and several documents
By default a string is quoted only when it has to be, with single quotes when possible. You can force double quotes or single quotes for every string and key, though a string that needs escapes is always double-quoted.
Quoting only when needed (default)
a: x b: 'yes' c: it's
Always double quotes
"a": "x" "b": "yes" "c": "it's"
Always single quotes
'a': 'x' 'b': 'yes' 'c': 'it''s'
A top-level array can also be written as a stream of YAML documents, one per item, separated by three dashes. This is the form used for Kubernetes manifests and for log-like data.
JSON input, a top-level array
[
{
"id": 1,
"name": "first"
},
{
"id": 2,
"name": "second"
}
]
Default: one sequence
- id: 1 name: first - id: 2 name: second
Top-level array as several documents
--- id: 1 name: first --- id: 2 name: second
Wrapping long lines
With a line width such as 40, long single-line strings are folded at single spaces onto continuation lines. YAML reads the folded lines back as one line with spaces, so the value is the same. Keys are never folded, and neither are literal blocks or flow style.
JSON input
{
"description": "This sentence is deliberately long so that it has to be folded across several lines when a narrow line width is chosen."
}
No wrapping (default)
description: This sentence is deliberately long so that it has to be folded across several lines when a narrow line width is chosen.
Line width 40
description: This sentence is deliberately long so that it has to be folded across several lines when a narrow line width is chosen.
Numbers and keys that need care
Numbers are copied exactly as they were typed, including a 20-digit integer that a JavaScript number would round, a trailing zero and a negative zero. A number with an exponent, such as 1e3, gets a decimal point and a sign when it lacks them, because some YAML readers do not accept the short form as a number. The value is the same.
Output for 12345678901234567890, 1.50, 1e3 and -0
big: 12345678901234567890 price: 1.50 exp: 1.0e+3 zero: -0
Keys are strings in JSON, so a key that looks like a number, a boolean or a date is quoted to stay a string, and so is an empty key or one containing a colon:
Output for the keys 1, yes, a:b and the empty key
'1': one 'yes': 'y' 'a:b': c '': empty ok: fine
What does the YAML to JSON converter bring back?
We converted a set of documents with this page and read the result back with the YAML to JSON converter using its default options. Every structure came back equal, including strings from the traps above, awkward keys, nested and empty collections, multi-line text, Unicode, flow style, sorted keys, four-space indentation, always-double quoting and a top-level array written as documents. The one difference was a number above the safe integer range, such as 12345678901234567890: this page writes it exactly, and the YAML to JSON converter reads it back as a string with the same digits instead of a number.
Common problems and how to fix them
A value changed type after loading
If a loader turned a string into a boolean or a date, the YAML was probably written by hand or by a tool that does not quote. Re-create it here, and every risky string is quoted.
Indentation errors
YAML uses spaces only. This page never writes tabs for indentation and keeps list items consistently aligned, with a nested block starting two columns after its dash.
A multi-line string lost its trailing line break
Check the sign after the pipe. A minus strips the last line break, which is correct for a string that did not end with one.
Different tools expect different YAML versions
The output is written to be read the same way by YAML 1.1 and 1.2 readers, which is why yes and no are quoted although YAML 1.2 would accept them plain.
Should I use YAML or JSON?
YAML is easier for people to read and edit, allows comments, and is the usual choice for configuration kept in a repository. JSON is stricter and simpler to generate and parse, and it is the better choice for data exchanged between programs. Because YAML is sensitive to indentation and to the type guessing described above, generated YAML is safest when a tool writes it, which is what this converter is for. After converting, compare the result with the original using the JSON compare tool.
What are the limits of this converter?
Input of up to 100 MB is accepted. Anything above about 1.5 MB is converted straight from the file in a background worker, with a time limit that grows with the size, a Cancel button and a busy indicator. Nesting is limited to 1,000 levels, although the YAML to JSON converter reads at most 100. The converter does not write comments, anchors, aliases, tags or merge keys, and it does not choose between YAML versions. Keys that look like whole numbers come first, because that is how JavaScript orders object keys.
Related tools
Frequently Asked Questions
How do I convert JSON to YAML?
Paste your JSON, choose a .json file or load the sample. The YAML appears as soon as the JSON is valid. Choose the indent, key sorting, quoting and style options if you need them, then copy the YAML or download it as a .yaml file.
Why are some strings quoted, such as 'NO' and '1.0'?
YAML reads an unquoted NO, yes, on, null, 1.0, a date such as 2026-10-20 or an empty value as something other than a string. The converter quotes every string that any common YAML reader would misread, so the data keeps its meaning when the YAML is loaded.
How are multi-line strings written?
As literal blocks that start with a pipe, which keep every line break exactly, with the right marker for a trailing line break. Turn the option off to get a quoted string with \n escapes instead. A string with control characters or tabs is always quoted with escapes.
Can I write flow style, sort the keys or create several documents?
Yes. Flow style writes the whole document with braces and brackets, Sort keys orders every object's keys alphabetically, and Top-level array as several documents writes each item as its own document separated by three dashes. You can also choose 2 or 4 spaces, a line width, and null or ~ for null values.
Is my JSON uploaded anywhere?
No. The JSON is converted by a script running in your browser tab, and the converter does not send it anywhere. The page uses Google Analytics for anonymous usage counts, which never include your JSON, keys or file names.
Are big numbers and number spellings kept?
Yes. A number is copied exactly as it was typed, so 12345678901234567890 and 1.50 are unchanged. Only a number with an exponent gets a .0 and a sign added when it lacks them, as in 1.0e+3, because some YAML 1.1 readers read 1e3 as text.
Built and maintained by Deepak Kumar.