About JSON to YAML & TOML Converter
JSON to YAML & TOML Converter parses a JSON document and re-emits it as YAML or TOML, side by side with the original, so you can move a configuration between formats without retyping it. The conversion is structural — keys, nesting and order are preserved — but the type systems are not identical, and the interesting work is checking what changed.
The three formats agree on maps, lists, strings, numbers and booleans, and disagree about almost everything else. JSON has one number type, no comments, no dates and no way to express a reference. YAML adds comments, anchors, block scalars and — depending on which version of the specification your reader implements — implicit typing rules that will happily turn a string into a boolean. TOML adds real date and time types and a strict table model, but has no null at all. A conversion that succeeds is a starting point, not a finished file: the output is syntactically correct, and whether it still means the same thing depends on the parser that reads it next.
How to use this developer tool
- Paste valid JSON into the left pane. The document is parsed first, so a syntax error is reported before any conversion is attempted.
- Switch the format control to YAML or TOML. The right pane shows the result after you convert, and the copy button takes the whole output.
- Read the output for implicit typing, not for layout. Look at every value that could be mistaken for a boolean, a number, a date or a time if the quotes were removed.
- For TOML, compare the key count against the input. Keys whose value is null do not appear in the output at all, because TOML has no null.
- Parse the result with the loader that will actually consume it — PyYAML, SnakeYAML, go-yaml, tomllib — before committing it. That round trip is the only real proof.
Worked example: the Norway problem, live
Six ordinary configuration values converted to YAML. The output is valid and correct — under YAML 1.2. Read it with a YAML 1.1 parser and three of the six change type.
{
"country": "no",
"version": "1.10",
"release": "2026-09-21",
"window": "12:30",
"replicas": 5432,
"tls": { "enabled": false, "ca": null }
}country: no
version: "1.10"
release: 2026-09-21
window: 12:30
replicas: 5432
tls:
enabled: false
ca: nullThe emitter quoted "1.10" because unquoted it would be the float 1.1, but it left country, release and window bare, because in YAML 1.2's core schema all three are plain strings. Load the same file with PyYAML, SnakeYAML or gopkg.in/yaml.v2, all of which implement YAML 1.1, and country becomes the boolean false, release becomes a date object, and window becomes the integer 750 — twelve sixties plus thirty, because YAML 1.1 has base-60 integers.
What each format can express
Read this the way you would read a compatibility matrix: the rows where the three columns disagree are exactly the rows where a conversion can silently change meaning.
| Capability | JSON | YAML | TOML |
|---|---|---|---|
| Comments | None at all | # to end of line | # to end of line |
| Null | null | null, ~, or an empty value | No null type; a null-valued key is dropped from the output |
| Numbers | One number type, an IEEE 754 double | Integer and float distinguished | Integer and float distinguished; 5_432 is a legal integer and is what the writer emits |
| Dates and times | None; a date is a string | Timestamp type in 1.1; a plain string under the 1.2 core schema | First-class offset date-time, local date-time, local date and local time |
| Multi-line strings | Escapes such as \n only | Block scalars with | and > | Triple-quoted """ and ''' |
| Top-level value | Any value, including an array | Any value, including a sequence | Must be a table; a top-level array cannot be written |
| Duplicate keys | Accepted; the last one silently wins | An error in 1.2, though older parsers keep the last | An error |
| Mixed-type arrays | Allowed | Allowed | Rejected by the writer used here |
| Key containing a dot | Ordinary key | Ordinary key | Must be quoted, because a bare dot means nesting |
| Reuse within a document | None | Anchors with & and aliases with * | None |
Troubleshooting
A string value arrives at the application as a boolean, a date or a number.
Why it happens YAML 1.1 implicit typing. no, yes, on and off are booleans, 2026-09-21 is a timestamp, and 12:30 is the base-60 integer 750. The emitter here follows YAML 1.2, which has none of those rules, so it leaves the values unquoted.
Fix Quote anything that could be read as another type before handing the file to a YAML 1.1 parser, which is most of them: PyYAML, SnakeYAML and gopkg.in/yaml.v2 all are. Country codes, version strings, times and anything a human might type as y or n are the usual casualties.
Keys are missing from the TOML output.
Why it happens TOML has no null. A key whose JSON value is null has nothing to be written as, so the writer omits the key entirely rather than inventing a value.
Fix Decide what null means for that setting before converting. Either remove the key from the JSON, so its absence is deliberate, or replace null with the real default the application would have used.
TOML conversion fails outright.
Why it happens Two common reasons. A TOML document must be a table, so a JSON document whose top level is an array cannot be written at all. And the writer rejects an array whose elements are not all the same type, so [1, "two", {"three": 3}] stops the conversion.
Fix Wrap a top-level array in an object under a named key. For a mixed array, either split it into separate homogeneous keys or convert to YAML instead, which has no such restriction.
A version number loses a digit somewhere downstream.
Why it happens Unquoted, version: 1.10 is the float 1.1 in every YAML version, and 1.10.2 is a string only because it has two dots. The same trap catches zero-padded values: build: 007 is the integer 7.
Fix Quote every version, build number, zip code, phone number and identifier, without exception. The converter does this for you on the way out; a human editing the file afterwards will not.
When this tool is the right choice
- Porting an existing JSON configuration into a YAML-based tool such as Kubernetes, GitHub Actions or Docker Compose.
- Producing a TOML starting point for a Rust, Python or Hugo project from data you already have in JSON.
- Seeing the shape of a deeply nested document more clearly, since YAML indentation and TOML tables both scan better than braces.
- Checking, before you commit, which values a YAML parser might reinterpret if they were left unquoted.
When to use something else
- Validating the JSON itself. Paste it into the JSON Formatter & Validator first, which reports the exact offset of a syntax error.
- Converting the other way. YAML and TOML both carry constructs — comments, anchors, dates, multi-line scalars — that have no JSON equivalent, so a round trip is lossy by construction.
- Checking that the result is a valid configuration for your application. The converter validates formats, not schemas; required keys and cross-field rules belong to the application's own loader.
Privacy and data handling
Parsing and emitting both happen in this browser tab, using the YAML and TOML libraries bundled with the page; no document is uploaded and nothing is kept after the tab closes. Configuration files are the single most common place to find a database password in plain text, so replace those with placeholders before pasting, and remember that the output pane is as readable to a screen-sharing audience as the input pane.
Related developer tools
Frequently asked questions
Will my comments survive?
There are none to survive. JSON has no comment syntax, so nothing can be recovered from a JSON source. Add comments to the output after deciding where the file will live, and from then on treat that file, not the JSON, as the source of truth.
Which YAML version does the output target?
YAML 1.2 and its core schema, which is what the emitter quotes for. That is the current specification, but a large share of deployed parsers still implement 1.1, which has extra implicit types. When you do not know the reader, quote defensively.
Why does TOML write 5_432 instead of 5432?
Underscores are legal digit separators in TOML integers and the writer inserts them for readability. Every conforming parser ignores them, so the value is exactly 5432. If a downstream tool chokes, it is not TOML-conformant.
Is key order preserved?
Yes, output follows the order of the parsed JSON object. TOML additionally hoists nested objects into [table] sections that appear after the scalar keys of their parent, which the format requires, so the file reads in a slightly different order than the JSON did.
What happens to very large integers?
They are already damaged before the converter runs. JSON numbers are parsed as doubles, so 9007199254740993 becomes 9007199254740992 during parsing. Serialise large identifiers as JSON strings and they survive as quoted strings in both YAML and TOML.
Can I convert a top-level JSON array?
To YAML, yes — it becomes a sequence. To TOML, no: a TOML document is a table, so there is no place for a bare list. Wrap the array in an object with a descriptive key, which the resulting TOML would have needed anyway.