Convert YAML to JSON and back
One tool for both directions: the direction is worked out from the file, multi-document YAML is supported, and every error names its line.
Drop your files here
.yaml, .yml, .json, .txt · up to 300 MB
More settingsFewer settings
How to convert YAML to JSON and back
- 1
Drop a YAML or JSON file
Add one file or up to twenty. Extensions .yaml, .yml and .json are all recognised, and a batch may mix them freely.
- 2
Check the detected direction
The direction is chosen from the extension, or from the content for plain text. Override it whenever the automatic guess is not what you meant.
- 3
Convert and download
Press the button and save the converted file. Several files come back as one ZIP archive.
Why the direction has to be guessed carefully
Every valid JSON document is also valid YAML, so testing a file against a YAML parser first would classify a plain .json file as YAML and convert it to itself. The extension therefore wins: .json converts to YAML, .yaml and .yml convert to JSON. Only for .txt and other unlabelled input does content decide, and JSON is tried first for exactly the same reason.
A duplicate key is an error, not a preference
In JSON the last value of a repeated key wins, quietly. In YAML the same repetition is a mistake worth stopping for, because config files are where it happens: a docker-compose.yml with ports listed twice at the same level silently cancels the first list, and the discovery is usually made in production. Both line numbers are reported so you can see which definition was about to disappear.
Four schemas, and what a narrower one buys
The default schema resolves the usual YAML types, including dates and binary blobs. Core and json are progressively stricter, and failsafe recognises only strings, maps and sequences. Choose a narrow one when a config must be read as literal data: it stops the classic YAML surprises where a version number becomes a float and no becomes false.
Configs stay on your machine
Config files carry hostnames, ports, bucket names and sometimes worse, which is exactly why this conversion happens in your browser tab rather than on a server. Parsing and printing both run locally, in a worker thread, on code that shipped with the page. Nothing is uploaded, nothing is queued and nothing survives the tab being closed.
Frequently asked questions
How is the conversion direction chosen?
By file extension first: .json goes to YAML, while .yaml and .yml go to JSON. For .txt and other unlabelled files the content decides: the text is tried as JSON first, then as YAML. If neither parses you are told so and can pick the direction yourself.
What happens to a YAML file with several documents?
A file split by --- markers can be read either way. With multi-document mode on, every document becomes an element of one JSON array. With it off only the first document is converted and you get a non-blocking warning telling you the rest were ignored, so a truncated result is never a silent surprise.
Why is a duplicate key treated as an error?
Because in YAML the second definition overwrites the first without any sign that it happened. That is a common way to lose a port mapping or an environment variable in a config file. The conversion stops and names the key together with both line numbers, so you decide which definition was meant.
What is the failsafe schema and when do I need it?
Failsafe resolves only strings, mappings and sequences; nothing is turned into a number, boolean, date or null. It is the right choice when a config must be preserved literally, for example when a value like 1.10 is a version rather than a number, or when the Norway problem is turning the country code no into false.
Are YAML comments kept in the JSON?
No, and they cannot be. JSON has no syntax for comments at all, so anything after a # is dropped during conversion. This is a property of the target format rather than a gap in the tool, so keep the YAML as the source of truth if the comments matter to you.
What does the flow level change?
It decides at which nesting depth YAML output switches from block style, with dashes and indentation, to inline style like [a, b] and {a: b}. The default keeps every level in block style, which reads best for hand-edited configs. Setting a positive depth compacts everything below it, which suits deeply nested data.
Are anchors and aliases supported?
No. Anchors, aliases and merge keys (&defaults, *defaults and <<), along with custom application tags, are outside what this tool reads. A file using them gets a clear error naming the line rather than a quietly wrong result, which is the safer failure for a config you are about to deploy.
Does my file get uploaded anywhere?
No. Both parsers ship with the page and run inside your browser tab, so your configuration never travels over the network. There is no server component to store it, and nothing is retained once the tab is closed.
Related tools
JSON FormatterIndent, minify or just check a JSON file, with the error located by line and column and the quiet problems named out loud.
JSON to ExcelFlatten a JSON or NDJSON export into a spreadsheet. Nested objects become dot-named columns and every record contributes its keys.
XML FormatterIndent XML so a human can read it, collapse it onto one line, or just check it; comments, CDATA and attribute order come out untouched.
JSON to XMLBuild a valid XML document from JSON: you name the root and item tags, and keys XML cannot accept are repaired rather than dropped.
Compare TextTwo columns, deletions in red and additions in green, with the changed words picked out inside each line.
SQL FormatterIndent a query by its nesting, bring keywords to one case, or squeeze the whole thing onto one line for a log, across fifteen dialects.