JSON YAML Converter

All three describe the same thing — nested key/value data — but they optimize for different jobs. JSON (JavaScript Object Notation) is strict and machine-first: it uses braces and brackets, has no comments, and rejects trailing commas, which makes it the standard for web APIs and package.json. YAML uses indentation instead of braces, allows comments, and is far easier to read and edit by hand, so Docker Compose, Kubernetes, and GitHub Actions workflows use it. TOML aims for an obvious, unambiguous config file and powers Rust's Cargo.toml and Python's pyproject.toml. Because they are interchangeable representations of one data tree, you can author in whichever feels comfortable and convert to whatever a given tool demands. Paste your data above, pick a direction, and this converter handles all six pairings between the three formats instantly.

JSON has no concept of comments at all — the format simply does not allow them, so there is nothing to carry over when you convert in that direction. YAML and TOML both support comments, but converters work on the parsed data tree, not the raw text, so comments are not round-tripped between formats automatically. If you start with a YAML file full of explanatory comments and convert it to JSON and back, those comments will be gone. To keep comments while editing, stay within YAML or TOML rather than routing through JSON. If your input is JSON with comments or trailing commas, switch on the JSON5 input mode so the looser dialect parses cleanly instead of erroring. Paste your file above and the converter validates and formats it as you type, flagging the line where any syntax problem occurs.

Scrolling through a deeply nested document to find one value is slow and error-prone. This tool includes a JSONPath query box that pulls specific values out of the converted output without hunting by hand. JSONPath uses dot and bracket syntax: $.dependencies returns that object, $.scripts.start returns a single string, and $.services.*.image uses a wildcard to grab the image field from every service in a Docker Compose file. The $ refers to the root, and you chain keys to drill down. There is also a schema stats panel that summarizes structure at a glance — total keys, object and array counts, null values, and how deeply the data nests — which is a fast sanity check on an unfamiliar payload. Paste your data, convert it, then query the result directly above.

A correct round-trip preserves your data because all three formats are just different ways of writing the same key/value tree — strings, numbers, booleans, nulls, objects, and arrays map cleanly between them. What changes is presentation, not meaning: key order can shift unless you keep it, indentation style differs, and formatting like quotes or braces is rewritten. Comments do not survive a trip through JSON, since JSON cannot hold them. To confirm nothing was altered, use the side-by-side diff view, which highlights exactly what changed between input and output so you can verify a round-trip kept your values intact. You can also turn on sort keys for a stable, comparable order before comparing. Paste your file above, convert it, and check the side-by-side diff before you copy or download the result.

Minify strips a document down to the most compact valid form, removing every optional space, line break, and indent so the output is a single dense block. For JSON that means no pretty-printing — ideal when you are embedding data in a URL, a config value, an API request body, or anywhere smaller payload size and fewer bytes matter. It is the opposite of pretty formatting, which adds whitespace for human readability. You would minify before shipping to production or pasting into a field with a length limit, and keep it formatted while editing or reviewing. The converter also lets you set indentation (commonly 2 or 4 spaces) and sort keys alphabetically for the non-minified view. Paste your data, toggle minify, and copy or download the compact result with the correct file extension.