Skip to main content

JSON to YAML converter

Convert JSON data to YAML format

No watermarkFree & unlimited
Mode
Input (JSON)
Output (YAML)
All processing happens in your browser. No data is sent to any server.

Your JSON is parsed by the browser and then written back out by js-yaml with three settings that shape the result: two-space indentation, a line width of 120 characters, and references turned off. That last one matters most. When the same object appears twice in your data, YAML would normally emit an anchor and an alias to save space; here both copies are written in full, so the file stays readable and can be understood without following pointers. Quoting is added only where a value would otherwise be ambiguous.

Key facts about JSON to YAML converter

Key facts about JSON to YAML converter
Writerjs-yaml 4.1 dump, configured with indent 2, line width 120 and references disabled.
Anchors and aliasesNever written. A repeated object is expanded at every occurrence rather than referenced with an ampersand.
Line foldingScalars longer than 120 characters are folded across lines, which reads better but changes where breaks fall.
QuotingApplied only when needed, so a string that looks like a number, a boolean or a date is quoted to survive re-reading.
Key orderPreserved exactly as the JSON declared it, so the YAML can be diffed against the source line by line.
Document markerNo leading three dashes are emitted, so append your own if the destination expects an explicit start.
CommentsImpossible to generate. JSON carries none, so the YAML arrives without explanatory notes anywhere.
NullsWritten as the bare word null rather than as a tilde or an empty value, which reads unambiguously.
Empty containersAn empty object becomes a pair of braces and an empty array a pair of brackets, using flow style for both.
Typical size deltaYAML is usually 10 to 25 percent shorter than the same data as indented JSON, because brackets and quotes go away.
Input strictnessValid JSON only. Trailing commas, comments and single quotes stop the conversion with a parse error.
ModesPaste and convert, or upload a .json file, with copy on the output and live character counts.

What happens to your file

JSON payloads and config files routinely carry tokens, keys and personal data, so it is worth being precise: this conversion is done by JavaScript in your own tab. Pasted text stays in the input panel, an uploaded file is read with the File API, the browser parses the JSON, and the copy of js-yaml bundled into this page writes the YAML. The result becomes clipboard text or a local Blob download. No network request carries any part of it, and nothing persists after a reset.

About this tool

  1. 1

    Choose paste or upload

    Paste and convert is selected by default; switch to file upload to convert a .json file from disk.

  2. 2

    Supply valid JSON

    Objects, arrays or a bare value all work, but the text must parse strictly, with no comments or trailing commas.

  3. 3

    Convert

    js-yaml dumps the parsed value with two-space indentation, folding long scalars at 120 characters.

  4. 4

    Add what YAML files usually carry

    Insert comments, and a leading document marker if your tool expects one, once the structure is in place.

  5. 5

    Copy or download

    Copy the YAML to the clipboard, or save a .yaml file if you converted from an uploaded document.

Specs & compatibility
Input and outputTakes .json (application/json) and returns the YAML as a blob with the text/yaml type, named after the file you dropped in.
EngineJSON.parse reads the file and js-yaml 4.1.1, bundled into the page, dumps it as YAML - no worker and no network call.
ModesBoth modes: paste the JSON in and copy the YAML straight back out, or hand over a file and take the YAML as a download.
Batch and capsTwenty JSON files per run at 500 MB each; several YAML results are zipped in page memory as converted-yaml-files.zip.
Browser and deviceJSON to YAML needs only the File API, a Blob download and the parser already in the bundle, so every current browser behaves the same and the page keeps working with the network off.
  • Check every string that looks like something else. The writer quotes values such as 1.10, true and 2026-01-31 precisely so they come back as strings, and removing those quotes by hand will change their type.
  • Long URLs and description fields fold at 120 characters. If a downstream parser is fussy about exact strings, verify the folded value reads back identically before relying on it.
  • Repeated blocks are written out in full rather than as anchors, so a config with heavy duplication gets longer. Introduce anchors by hand if compactness matters more than clarity.
  • Add the comments the file deserves straight after converting. They are the main reason teams prefer YAML for configuration, and no converter can invent them.
  • If the target is a multi-document file such as a Kubernetes bundle, separate the documents yourself with three dashes; the dump produces one document only.
  • Move an API response or an exported settings blob into a hand-editable configuration file for a CI system or a deployment.
  • Convert a JSON OpenAPI description into YAML so the specification is easier to review in a pull request.
  • Produce a readable YAML fixture from a JSON sample before adding the comments a teammate will need.
The dump runs with references disabled, so js-yaml never emits an anchor and alias pair even when it detects the same object more than once. The reasoning is readability: a file full of asterisk references is compact but hard to follow, and many simple consumers handle them poorly. The cost is length, so add anchors yourself if a large config repeats heavily.
Because without quotes they would be read back as something else. A value like 1.10 would load as the number 1.1, the word true would become a boolean, and a date-shaped string would become a timestamp. The writer detects these cases and quotes them so that converting the YAML back to JSON returns exactly the strings you started with.
No, and no converter can. JSON has no comment syntax, so the source contains nothing to carry across, and inventing explanations would be worse than leaving them out. This is the one thing a JSON to YAML step always loses in the round trip: you gain a friendlier format, and you have to write the documentation into it yourself afterwards.
It does not. The document start marker is optional in YAML and is omitted here, which is fine for most single-document configs. Tools that concatenate several documents into one stream, Kubernetes bundles being the usual example, do expect the marker, so add it at the top of each document if you are assembling such a file.
Usually ten to twenty-five percent fewer characters than the same data serialised as indented JSON, because braces, brackets, the quotes around keys and the commas between entries all disappear. Data that is mostly deeply nested objects benefits most; data that is mostly long strings barely changes, since the strings dominate either way.
Yes, and the pair is designed to round-trip. Because the writer quotes ambiguous scalars, reading the YAML back with the companion converter returns the same types and the same key order you started with. What will not come back are any comments or anchors you added by hand afterwards, since neither has a JSON equivalent.

Related tools

View all

Need the opposite? Try YAML to JSON

Related categories1

Updated

We use anonymous analytics to improve ToolChamp. No personal data is stored or sold. Privacy Policy