Skip to content
ToolBoxGeniehome

TOML to JSON Converter

Developer Tools · Added

Paste a TOML config and get JSON, or paste JSON and get TOML. Both directions run in this page. The parser implements TOML 1.0.0 properly — tables, arrays of tables, dotted keys, every string form, and integers in four bases — and it refuses anything it cannot read rather than quietly turning it into something plausible.

Direction

JSON

Keys
15
Tables
6nested objects
Arrays
4

Everything runs in this page. Nothing you paste is uploaded, logged or stored, which matters here because config files are exactly where tokens and connection strings live.

How to use the toml to json converter

  1. 1Choose the direction: TOML to JSON, or JSON to TOML.
  2. 2Paste your config, or type into the box. Conversion happens as you type.
  3. 3For JSON to TOML, decide what to do about nulls and whether to sort keys — TOML has no null, so it is either dropped or reported.
  4. 4Copy the result or download it, or use Send back through to feed the output straight back in and check the round trip.

Examples

A section of pyproject.toml

Input
A [project] header with a name, a version and a dependencies array
Result
A project object holding two strings and an array of strings

Keys written after a header belong to it, so the position of a line in the file changes its meaning.

An array of tables

Input
[[bin]] twice, each with a name and a path
Result
A bin array holding two objects

Double brackets append to an array; single brackets would be a duplicate table and an error.

Something that will not parse

Input
port = 8080x
Result
Refused: 8080x is not a valid number, reported at line 1

A permissive parser would hand back the string 8080x, which looks correct and is not.

About the toml to json converter

Why TOML exists, and where it fits

TOML was designed to be an obvious configuration format — readable without a specification in hand, and unambiguous enough that two implementations agree. It sits between INI, which has no agreed grammar at all, and YAML, whose flexibility is the source of most of its surprises. It is now the standard for Rust projects through Cargo.toml and for Python packaging through pyproject.toml, which is why most people meet it for the first time when a tool tells them to edit one.

Its central idea is that a document is a table, and headers in square brackets name the sub-table that following keys belong to. Nearly everything else follows from that, including the piece that catches people out: a key/value pair written after a header belongs to that header, so the position of a line in the file changes its meaning.

Arrays of tables, the part worth understanding

Single brackets name a table; double brackets append a new element to an array of tables. Writing [[bin]] twice gives an array of two objects, whereas writing [bin] twice is a duplicate definition and an error. It is the one piece of TOML syntax that is hard to guess from context, and it is exactly what a list of build targets, dependencies or test matrices needs.

The related rule is that a header after an array of tables attaches to the most recent element. After [[fruit]] with a name, a [fruit.skin] header describes the skin of that fruit rather than of the array as a whole. That is what makes nested structures usable, and it is why the order of headers in a TOML file carries real meaning.

Converting to JSON is lossy in one direction only

JSON is the smaller language. It has objects, arrays, strings, numbers, booleans and null; TOML has all of those except null, plus four date and time types, integers in four bases, and several string forms with different escaping rules. Going from TOML to JSON therefore discards type information — a date becomes a string, a hex literal becomes a decimal number — while the values themselves survive intact.

Going the other way, the only thing JSON has that TOML lacks is null, which is why that is the one direction needing a decision from you. Everything else maps cleanly: objects become tables, arrays of objects become arrays of tables, and the rest are scalars.

Both directions run entirely in this page. That matters more than usual for this particular pair of formats, because config files are where connection strings, deployment secrets and API tokens tend to live — nothing you paste here is uploaded, logged or stored.

Frequently asked questions

What happens to TOML dates?
They arrive in JSON as strings, and the page tells you how many did. TOML has four first-class date and time types — offset date-time, local date-time, local date and local time — and JSON has none at all, so the text is preserved exactly while the type is not. Going the other way they stay strings, deliberately: deciding that a string is a date because it happens to look like one would corrupt any config holding an ISO-8601-shaped identifier, and a converter that damages valid input to be clever is worse than one that leaves it alone.
TOML has no null. What happens to mine?
Your choice, from two options, because there is no third that is honest. Dropping the key is the default and is what a configuration file usually wants, since an absent key is the closest thing TOML has to an absent value. Refusing outright is the other, and it is the right setting for a data conversion where losing a field silently would matter. Writing the string null is not offered: it would turn a missing value into a present one, and any program reading the result afterwards would be wrong in a way nothing would flag. Nulls inside an array are always an error, since removing one would shorten the array and shift every index after it.
Why does it reject things other converters accept?
Because a config parser that guesses is more dangerous than one that stops. If 8080x quietly becomes a string, or a duplicated key silently keeps the last value, you get output that looks entirely correct and is not — and the failure surfaces later, in production, a long way from the conversion that caused it. Everything here that cannot be read with certainty is refused with a line and column number instead, which includes duplicate keys, duplicate table headers, a key that would extend an inline table, and numbers with anything trailing them.
Are very large integers safe?
Not entirely, and you are told when they are not. TOML integers are 64-bit, while a JavaScript number holds only 53 bits of integer precision exactly, so anything beyond about nine quadrillion cannot survive the trip and is rounded. This affects snowflake identifiers and large database keys in particular. The conversion counts these and reports them rather than letting a value change quietly — if it fires on your file, hold those identifiers as strings in the TOML rather than as bare integers.
Does the round trip give me back exactly what I started with?
The data does; the formatting does not, and it cannot. Comments are not part of the data model, so they are gone once the file is parsed. Key order within a table may move, because scalars have to be written before the first sub-table header or they would silently belong to that table instead. Inline tables come back as full table headers, and dates come back as quoted strings. Use Send back through to see exactly what your own file does — the values will match, the layout will be tidied.

Related tools