JSON to TOML Converter

TOML was designed as a configuration language with obvious semantics, and that design imposes constraints JSON does not have. Two of them will decide whether your document converts at all. A TOML document is a table — a set of key-value pairs — so the top level of your JSON must be an object; a bare array or a bare scalar has nowhere to go. And TOML has no null, at all, by deliberate decision: the way to express absence in TOML is to omit the key.

When those two conditions are met the conversion is clean, and the output is a genuinely nicer configuration file than the JSON was — Cargo.toml, pyproject.toml, Netlify and Hugo configs, and a great deal of Go and Rust tooling all use it for good reason. Everything runs in your browser in a Web Worker.

How JSON structures map onto TOML

• Top-level scalars become bare key-value pairs at the head of the file, before any table header. TOML requires this: once a [table] header appears, every following key belongs to that table until the next header, so anything at the root must come first.
• Nested objects become tables. {"server": {"host": "0.0.0.0"}} becomes a [server] section. Deeper nesting becomes a dotted header such as [server.tls], which reads far better than three levels of JSON braces.
• Arrays of objects become arrays of tables. This is TOML's best feature and its least familiar syntax: a list of rate-limit rules becomes repeated [[rate-limit]] blocks, each with its own keys. It is much easier to edit and to diff than the equivalent JSON array.
• Arrays of scalars become inline arrays in square brackets, wrapped across lines if they are long.
• Strings, numbers and booleans map directly. TOML distinguishes integers from floats, so a JSON 8080 becomes the integer 8080 and 0.05 becomes a float.
• Keys are quoted only when required. A key of letters, digits, underscores and hyphens is written bare; anything else — a key with a space or a dot in it — is quoted. Note that a bare key containing a dot would be read as a path into a nested table, so quoting there is not cosmetic, it is what preserves your data.

Null, and why TOML refuses it

A JSON document containing null anywhere cannot be converted, and the error will point at that. This is not a gap in the converter — TOML has no null value and the specification has repeatedly declined to add one, on the grounds that a configuration key with no value is the same as a key that is not there, and that having two ways to say "absent" invites bugs.

So the fix is a modelling decision, not a syntax one. Ask what the null actually means in your data. If it means "not configured", delete the key and let your application's default apply — that is idiomatic TOML and idiomatic configuration generally. If it means "explicitly disabled", use false or an empty string, which says so unambiguously. If it means "unknown", consider whether a configuration file is the right place for it at all.

The practical implication for round-tripping: JSON with nulls, converted to TOML by deleting the keys and converted back, gives you JSON without those keys. Absent and null are the same thing in TOML, and once you cross that boundary the difference is gone for good.

Dates, and what TOML has that JSON does not

TOML has first-class date and time types: an offset date-time such as 2026-03-11T09:14:02Z, a local date-time, a local date such as 2026-06-01, and a local time such as 22:00:00. They are real typed values in the data model, not strings, and a TOML parser hands your application an actual date object.

JSON has none of this. A timestamp in JSON is a string, and there is nothing in the document to distinguish "2026-03-11T09:14:02Z" from any other string. So when you convert JSON to TOML, an ISO timestamp comes out as a quoted string, not as a TOML datetime. That is the correct, conservative behaviour — promoting anything that looks like a date would eventually corrupt a version string or an identifier — but it does mean a date-typed field in your original system arrives in TOML as text.

If you want real TOML datetimes, remove the quotes by hand after conversion for the fields you know are timestamps. It is a small edit and TOML's date syntax is designed to be written by hand.

The other thing TOML offers that JSON cannot is comments, and for the same reason as YAML there is nothing to derive them from. Add them once you have the TOML — a configuration file without comments wastes most of the benefit of the format.