TOML to JSON Converter

What is a TOML to JSON converter?

TOML is a configuration format designed to be obvious to a person reading it: sections in square brackets, keys and values separated by equals signs, and no significant whitespace to get wrong. It is what Rust's Cargo, Python's pyproject.toml and a great many other tools use. JSON is what programs pass to each other. A converter turns one into the other, and this one does it in your browser.

The conversion is not a straight relabelling, and that is the interesting part. TOML distinguishes more kinds of value than JSON has room for, so some information is destroyed on the way across. Most converters do this silently. This one lists every value it had to flatten and where it was, so you can decide whether it matters before the output goes anywhere.

The parser is checked against the TOML project's own conformance suite: 210 valid documents that must parse to an exact result, and 499 that must be refused. It parses all 210 correctly and refuses every one of the 499 it can actually see — the six exceptions are documents containing invalid UTF-8 bytes, which no parser reading a browser text field can ever encounter.

How to convert TOML to JSON

1. Paste your TOML. Anything valid under TOML v1.0.0: tables, arrays of tables, inline tables, dotted keys, multi-line strings. The sample buttons load one of each interesting case.
2. Read the JSON. It appears immediately, formatted with two-space indentation, and there is a copy button. If the document does not parse, you get the rule that was broken and the line and column it happened at.
3. Check the loss panel underneath. It names every value JSON could not represent faithfully, with its path. On an ordinary config file it says nothing was lost, which is a measurement rather than a reassurance.

What JSON cannot carry across

TOML has four separate date and time types. An offset date-time pins an instant; a local date-time has no offset; a local date is a day with no time; a local time is a time with no day. All four are first-class values with their own syntax. JSON has no date type at all, so all four arrive as quoted strings, indistinguishable from a string that merely looks like a date. Load the second sample above and the panel names all four.

TOML also separates integers from floats, and JSON does not. That has two consequences. A float written 1.0 comes out as 1 and is now indistinguishable from the integer beside it. And a 64-bit integer — TOML guarantees the full signed range — cannot survive: JavaScript numbers are exact only to about 9 quadrillion, so 9223372036854775807 comes back as 9223372036854776000. The third sample shows both.

The clearest evidence that this is a real problem rather than a pedantic one is the TOML project's own test suite. Its expected outputs are not plain JSON — every single scalar is wrapped as an object carrying its type, across eight tags. The people writing the conformance tests could not express TOML's values in JSON either, so they invented an encoding that says what each value is. This converter's loss panel is the same admission, made where you can act on it.

Why there is no JSON to TOML button here

The reverse direction has a problem with no honest solution, and it is worth stating rather than hiding behind a half-working feature. TOML has no null. There is no spelling for it anywhere in the grammar — not a keyword, not an empty value, nothing. A key either has a value or is absent.

So a JSON document containing null cannot be converted. The options are to drop the key, which silently changes the document's meaning, or to write something that looks like null and is actually the four-letter string, which is worse. Neither is a conversion. A tool offering the button has to pick one and usually does not tell you which.

There are smaller problems in the same direction — JSON allows an empty key, and arrays of mixed shape that TOML's table syntax cannot express tidily — but null is the one that has no answer at all. If you need to go that way, the honest move is to decide what those nulls mean in your configuration first, because only you know.

Other things worth knowing

TOML is stricter than it looks, and the parser here holds to it. A key cannot be defined twice, a table cannot be reopened by a second header, and an inline table is closed the moment it is written — so a later [section] cannot add to it. Dates are validated rather than rolled over, so 2026-02-30 is an error and not the second of March. Leading zeros are not allowed on integers. Every one of these is a rule the conformance suite tests, and every one is a real bug avoided in a configuration file.

Comments and formatting do not survive. JSON has no comment syntax, so anything after a # is gone, along with your blank lines, your key ordering within a table and your choice of quoting. That is inherent to the target format rather than a shortcoming of the tool, and it is why converting a hand-maintained config to JSON is usually a one-way trip.

The parser accepts TOML v1.0.0, the released version. The unfinished 1.1.0 draft adds things this does not accept — trailing commas in inline tables among them — which is deliberate: a converter that accepts a draft nobody has shipped will happily read files that real tools reject.

Why is it free?

The parsing and the conversion both happen in your browser. Nothing you paste is uploaded, logged or stored — closing the tab is all the deletion there is. That matters here, because configuration files are exactly the sort of thing that carries a hostname, a path or a key you would rather not hand to a stranger's server.

No account, no sign-up, no limit on document size, and no watermark on anything you copy out.