Saltar al contenido principal
ToolsByUs

JSON to TOML

This converter emits TOML 1.0 from JSON entirely in your browser. Scalar keys are written first, then [tables], then [[arrays of tables]], so every definition precedes the headers it must precede. TOML-incompatible keys are flagged, nulls are refused with a named path, and a top-level array cannot convert — TOML has no anonymous root.

Solo local

La interfaz de esta herramienta está en inglés.

La guía de abajo solo está disponible en inglés.

JSON to TOML explained

The direction matters: JSON is usually born inside a program — an API payload, a stored document, a build tool's state — while TOML is usually read by a human configuring something. Converting JSON to TOML therefore means re-entering a format with real placement rules, and the biggest one is invisible until it bites: in TOML, a key's position in the file decides which table it belongs to. Write retries = 3 after a [servers] header and it silently becomes a key of servers, not of the root.

This converter emits scalar keys first, then [tables], then [[arrays of tables]], so every key/value pair is written under the header it belongs to and every table is fully defined before the next header opens. JSON objects become tables, arrays of objects become arrays of tables, arrays of scalars stay inline arrays, and every value is emitted as the TOML 1.0 type it already is — there is no inference step to get wrong.

Everything happens in this browser tab. The JSON you paste is parsed with the browser's own JSON.parse, the TOML is built from that document in memory, and nothing crosses the network — the Network panel in DevTools stays empty while you work, and the page's Content-Security-Policy keeps it that way.

The reverse crossing is the more common one — reading a Cargo.toml into a script — and the convert TOML back to JSON page handles it, keeping datetimes as strings exactly as this one receives them.

If the JSON came from a script rather than a formatter, run it through the JSON validator first — a document that fails to parse there will fail here too, with the same message.

Why scalars come first, then tables, then arrays

TOML's placement rule is the reason the output is ordered the way it is. Keys written after a [table] header belong to that table, and keys written after a [[array of tables]] header belong to its most recent entry — so an emitter that interleaved scalars and headers would produce a file that parses successfully into the wrong structure. Emitting a level's key/value pairs first, then its sub-tables, then its arrays of tables, is the only order that round-trips, and the same rule applies recursively inside every nested table.

Strings get one rule of their own: everything is emitted as a TOML basic string in double quotes, with backslashes, quotes and control characters escaped the way TOML 1.0 defines. The converter does not switch to literal strings to save punctuation, because deciding when a backslash is literal is exactly the guess a converter must not make. Keys follow the same discipline, so a key like port: 8080 arrives quoted and unambiguous.

The mapping from JSON to TOML

Every shape the converter handles, and its TOML 1.0 destination:

JSONTOML out
Object[table] header, keys beneath it
Array of objects[[array of tables]] entries, one per object
Array of scalarsInline array: ["fast", "safe"]
StringBasic string with standard escapes
Key with a dot or spaceQuoted key: "app.name" = 1
nullRefused — TOML 1.0 has no null

What the output looks like

The worked example below is the exact pair the converter's Load sample button produces: a root object with two scalars and an inline tags array, one nested owner object, and a servers array holding two objects. Notice the ordering — the root's plain key/value pairs, tags included, all appear before [owner], and both servers entries land under one [[servers]] header family in array order. That ordering is not cosmetic; it is what makes the file parse back to the same structure.

The same normalisation applies as everywhere in this family: output is generated from the parsed document, so indentation quirks in the source JSON are preserved in meaning and in key order, but re-printed in one consistent TOML style a reviewer can diff against.

Edge cases this converter refuses rather than mangles

Some inputs have no faithful TOML 1.0 representation, and pretending otherwise would hand you a config file that lies:

  • A top-level array or scalar — TOML documents are always a root table of key/value pairs, so a JSON file whose top level is not an object is refused with a clear message.
  • Any null, anywhere — TOML 1.0 has no null, so the converter refuses and names the exact path, leaving you to delete the key or choose a value deliberately.
  • Dotted-looking keys — a bare key a.b would parse as a dotted key and land in a nested table, so such keys are emitted as quoted basic strings, and the preview flags them so you can spot names that were probably meant as nesting.

Frequently asked questions

Is my JSON sent to a server during the conversion?

No. The conversion runs entirely in this browser tab: JSON.parse and the TOML writer are page-local JavaScript loaded once at open. There is no upload endpoint, and the Content-Security-Policy forbids the page from opening connections. DevTools proves it — watch the Network panel stay empty through any number of conversions.

Why must scalars be written before the [table] headers?

In TOML, every key after a [servers] header belongs to servers, so interleaving scalars and headers would change the meaning of the file while it still parses cleanly. Writing a level's key/value pairs first, then its sub-tables and arrays of tables, is the only order that parses back to the structure you started with — it is correctness, not style.

What does the converter do with JSON null?

It refuses. TOML 1.0 has no null value — the language offers no spelling for it — so no faithful emission exists. The converter reports the exact path of the offending key, such as owner.middle, and stops. Deleting the key, or substituting a sentinel string, is your decision rather than a silent guess baked into the output.

How are arrays converted?

By their contents. An array whose every element is an object becomes a [[array of tables]], one entry per object. An array of scalars or mixed values becomes a TOML inline array on one line, and an empty array is emitted as []. Nothing is flattened or reshaped — the converter renders the structure it was given, which is what makes the result predictable.

What happens to keys with dots, spaces or colons?

TOML bare keys allow only letters, digits, underscores and hyphens, so anything else must be a quoted key. This converter emits such keys as basic strings — "app.name" = 1 — which TOML 1.0 defines as a single key, not a dotted path. The preview flags quoted keys so you can see which names were probably intended as nesting and rename them by hand.

Can I get real TOML datetimes out of a JSON string?

Not by conversion, and honestly so. JSON has no date type, so the converter cannot know whether "1979-05-27T07:32:00Z" is a timestamp or a sentence that happens to look like one; every string is emitted as a quoted basic string. If you want a bare TOML datetime, remove the quotes in the output by hand — the text is already valid RFC 3339.

ToolsByUs team · How we check our tools