TOML to JSON Converter

What this converter does

This tool parses a TOML document — the format used by Cargo.toml, pyproject.toml and many app configs — and converts it into JSON. It resolves TOML's [section] headers into nested objects and its [[array of tables]] syntax into JSON arrays, so the output is exactly the data structure your code would see if you loaded the TOML with a library and then serialized it back to JSON.

When you need it

• Reading a Rust, Python or Go project's TOML config from a JavaScript or Node tool that only wants JSON.
• Debugging a TOML file by seeing its fully resolved structure — nesting and array-of-tables syntax can be easy to misread by eye, especially in a large file with many sections.
• Feeding TOML-based config into a system, API or validator that expects JSON.

Rules the converter applies

1. [section] headers become nested JSON objects. Every key inside a [service] block becomes a property of a "service" object in the JSON output.
2. [[array]] blocks become a JSON array of objects, with one array entry per repeated [[name]] header.
3. Inline arrays (ports = [8080, 8443]) become plain JSON arrays in the same order they were written.
4. TOML's native date and datetime values are converted to ISO 8601 strings in the JSON output, since JSON has no dedicated date type. Offset datetimes keep their offset (1979-05-27T07:32:00-08:00 becomes "1979-05-27T07:32:00.000-08:00"), and local dates and times stay local (1979-05-27, 07:32:00.000) with no time zone invented for them.
5. Invalid TOML stops the conversion, showing the parser's error and the line it occurred on rather than guessing.

TOML and JSON side by side

| TOML | JSON | Note | |---|---|---| | a = 1 | {"a": 1} | Flat key becomes an object property | | [b]
c = 1 | {"b": {"c": 1}} | Section header becomes nesting | | d = [ 1, 2 ] | {"d": [1, 2]} | Inline array stays an array | | [[e]]
f = 1 | {"e": [{"f": 1}]} | Array of tables becomes an array of objects |

Things to check after converting

• TOML integers are 64-bit, but JavaScript numbers are exact only up to 2^53 (about 9 × 10^15). An integer outside that range is rejected with an error rather than being rounded, so you never get a silently altered value. The special floats inf and nan have no JSON form and come out as null.
• Comments in the TOML source are dropped; JSON has no equivalent, so there's no way to preserve them through the conversion.
• If two [section] blocks with the same name appear in the file (invalid TOML, but sometimes produced by hand-edited files), the parser will report an error rather than silently merging them — fix the duplicate before converting.

Limits

Input is capped at 2 MB. The indent width of the JSON output is adjustable, from 0 (single line) to 8 spaces, so you can match whatever formatting convention your codebase uses.