Converters

JSON to YAML Converter

Convert JSON to YAML in your browser — paste JSON or drop a .json file to get indented, readable YAML back without an upload to a server.

JSON

Paste JSON above, drop a .yaml, .yml or .json file anywhere on this panel, or .

Paste or drop a YAML file above and this converts it to JSON — or paste JSON and get YAML back on the JSON to YAML converter page, which is the same tool starting in the other direction. Either way, the conversion runs entirely inside this browser tab, and when a document doesn't parse, the tool reports exactly which line and column broke it rather than a bare "invalid" message. Both directions come up constantly: YAML for a Kubernetes manifest, a docker-compose file or a CI pipeline; JSON for the API payload or config that has to come back out the other side.

YAML to JSON converter

This is the parent page's default direction, and it's usually the one people arrive holding: a Kubernetes manifest, a GitHub Actions workflow, or a config block that needs to become JSON for an API call or a script. The parser follows the YAML 1.2 core schema, which resolves a couple of everyday values in ways that genuinely surprise people used to older tools or hand-rolled scripts:

  • An unquoted number like 1.10 is read as a float, and JSON has no way to represent a float with a trailing zero, so it converts to 1.1. If that number is really a version string, quote it in the source ("1.10") and it survives the conversion unchanged.
  • no, off, yes and on stay strings, not booleans. Older, YAML 1.1-following tools read those as false/true — the "Norway problem", where a country code NO silently becomes the boolean false. This converter follows the modern, spec-correct reading instead: only true/false/null and their capitalised spellings ever get coerced.

Neither of these is a bug in the parser — every current YAML reader agrees with both — but they're exactly the kind of thing that's invisible until a converted file is subtly wrong days later.

JSON to YAML converter

Paste or drop a .json file here, or flip the direction control on the parent page, and you get indented, readable YAML back rather than the single-line, flow-style output some converters produce. Pick 2 or 4-space indent from the Indent selector — YAML has no minified form, so that third option only shows up when the target is JSON. Every JSON value round-trips the way you'd expect on this side: a null stays null, and strings, numbers, objects and arrays convert without any of the coercion surprises the other direction has, because JSON's types are already unambiguous going in.

Comments, anchors and multi-document streams: what a round trip loses

Converting YAML to JSON is lossy in ways worth knowing before you paste something you actually care about. JSON has no comment syntax at all, so every # comment in the source is dropped — the tool says so under the output rather than discarding it silently. Anchors and aliases (&name / *name) are expanded at the point each alias is used, so the JSON output holds a full copy of the anchored value everywhere it was referenced, instead of a single shared definition. And a multi-document YAML stream — one file with ----separated documents — doesn't collapse down to just the first document: it converts to a JSON array holding every document, with a note confirming the count, for example "2 YAML documents — converted to a JSON array of 2 items."

None of this is reversible by converting straight back. If a valid result gets swapped into the input to run the conversion in reverse, an Undo swap button appears specifically because that round trip won't reconstruct the comments, the anchors, or the original key order the source had — Undo restores exactly what you pasted rather than the closest the tool could rebuild from JSON alone.

Reading a conversion error: tabs, colons and duplicate keys

Invalid input is the ordinary case for a config file, not the exception, and the error band is built around that: it names the line and column, then adds a plain-sentence diagnosis for the everyday faults instead of a bare parser message. The single most common one is a tab used for indentation — YAML forbids a tab character anywhere in a line's leading whitespace outright, and because a tab is invisible in most editors, the fault can sit in a file for a long time before anything reads it and complains. Other named faults on the YAML side include a missing space after a colon (name:value instead of name: value), a line indented deeper or shallower than the block it belongs to, a duplicate key, and an unquoted value containing a colon that YAML starts reading as a second key by mistake. On the JSON side, the same list covers a trailing comma, a single-quoted string, an unquoted key, a smart quote pasted in from a word processor, and a stray NaN, None or True left over from Python. Where none of those apply, the band still gives a position and a plain message rather than guessing at a cause. A numbered excerpt of the source sits underneath with the failing line marked, and Jump to line moves the cursor straight to the offending span in the input so you don't have to hunt for it by eye.

Nothing you paste or drop leaves your browser

This matters more for a YAML tool than for most converters, because what actually gets pasted here is disproportionately a Kubernetes Secret, a docker-compose file with database credentials sitting in it, or a CI pipeline's environment block — and dropping a .yaml, .yml or .json file works too, taken straight off your disk rather than retyped. Parsing and emitting both happen inside this browser tab: there is no upload, and nothing is written to this browser's storage either, so leaving the page clears the input, the output and the dropped file's contents completely. A dropped file is checked by its extension rather than by the browser's guess at its file type, which varies by operating system for .yaml files specifically, and is capped at 2 MB — comfortably more than a config file needs, and small enough that parsing it never locks up the tab.

Questions

Why does my version number change when I convert YAML to JSON?
Because an unquoted number like 1.10 is read as a float under the YAML 1.2 core schema this tool follows, and JSON has no way to write a float with a trailing zero — so it converts to 1.1. That's spec-correct behaviour, not a bug in the parser: every current YAML reader agrees a bare 1.10 is a number rather than text. If the value is actually a version string, quote it in the source ("1.10") and it converts unchanged, because a quoted value is unambiguously a string. The built-in Load an example document quotes its own image tag this way on purpose, so the trap shows up before you hit it in a real file.
Why did my comments disappear after converting to JSON?
JSON has no comment syntax at all, so a # comment in your YAML has nowhere to go once the document becomes JSON — the tool drops them and says so under the output, with a note like "3 comments were dropped — JSON has no syntax for them," rather than discarding them silently. Your original YAML file is untouched; only the JSON copy this tool produces loses the comments. Converting the other direction, JSON to YAML, never shows this note, because JSON never had comments to lose in the first place.
Does this tool upload my YAML or JSON file anywhere?
No. Parsing and emitting both happen entirely inside this browser tab, and nothing is written to this browser's storage either — the input, the output and a dropped file's contents live only in this page's own memory, so a refresh, a navigation or closing the tab clears every byte of it. That's stricter than it needs to be for most converters, but a YAML paste here is disproportionately a Kubernetes Secret, a docker-compose file with database credentials in it, or a CI pipeline's environment block, and the file-drop option takes it straight off your disk rather than something you chose to retype — so nothing about it is kept around to be found on a shared machine later.
Why does it say tabs are not allowed?
Because the YAML specification forbids a tab character anywhere in a line's indentation, on every conforming reader — this converter isn't being unusually strict. The trouble is that a tab looks identical to spaces in most editors, so the fault can sit in a file for a long time before anything actually reads it and complains. The error names the exact line — "YAML does not allow tabs for indentation — line 7 begins with a tab character," for example — and the Jump to line button puts your cursor right there so you can retype that indentation with spaces.
How do I convert JSON back to YAML?
Switch the direction control at the top of the widget to JSON → YAML, or go straight to the JSON to YAML converter page, which starts in that direction already. Paste your JSON or drop a .json file, then pick 2 or 4-space indent from the Indent selector — YAML has no minified form, so that option only appears when the target is JSON, not when it's YAML.
Why did my YAML anchors and aliases turn into repeated text?
Because JSON has no equivalent of a YAML anchor (&name) and alias (*name) — each alias is expanded into a full copy of whatever it pointed at, at the exact place it was used, so the JSON output holds however many separate copies your YAML had aliases, not a shared reference. That loss is real and it's why, after a valid result gets swapped into the input to convert it back, an Undo swap button appears rather than the tool pretending the round trip was clean: converting YAML to JSON and back to YAML won't reconstruct the anchors, the comments, or the original key order the source had, so Undo restores exactly what you started with instead.