TOML to JSON Converter – Cargo.toml and pyproject.toml

TOML Input

JSON Output

Why you end up converting TOML at all

You have a Cargo.toml, a pyproject.toml, or a Netlify or Hugo config, and you want to do something programmatic with it — feed it to a script, diff two of them, or just see the shape clearly. TOML is pleasant to write and slightly awkward to reason about, because the nesting is implied by section headers rather than by indentation. Converting to JSON makes the structure explicit.

The construct that catches people out is [[table]] — a double-bracketed header. A single [server] declares one table; [[server]] repeated declares an array of them. In Cargo that is how you get several [[bin]] targets. In JSON it becomes an ordinary array, and seeing it that way once tends to make the TOML permanently readable.

The other surprise is that TOML has real types where JSON has strings. 2026-01-14T09:30:00Z is a first-class datetime in the TOML spec, not text that happens to look like one, and there are separate local-date and local-time types with no offset at all. JSON has no date type, so those come out as strings here — unambiguous ISO 8601, which is the closest JSON can get. A local date stays a bare "2026-01-14"; a local time gains a milliseconds field it did not have, which is the one cosmetic change on that path.

Numbers are where this page differs from every other TOML converter. The spec requires 64-bit signed integers to be handled losslessly, and JavaScript numbers hold about 15 digits, so a 19-digit SIM identifier is a problem that every browser-based converter has and most solve by silently rounding it. This one keeps the digits.

Converting a file

Paste or drop your TOML – Or open a .toml file with Upload — it is read in this tab and never sent anywhere, which matters when the config holds tokens. Sample loads a realistic file if you would rather see it working first.
Read the JSON as you type – Conversion runs about a third of a second after you stop typing, so you can edit a section and watch the shape change rather than converting, reading, and going back.
Check the syntax message if one appears – A parse failure names the line and column. TOML errors are usually one of three things: a bare string that needed quotes, a duplicate key, or a table header redefined after values were already assigned to it.
Copy or download – Two-space indented JSON. From there JSON to Table will show it as a grid, or JSON Formatter will reindent it.

If you are converting a Cargo.toml to compare two projects, convert both and use JSON Diff rather than diffing the TOML directly — TOML lets the same structure be written several ways, so a text diff shows formatting differences that a structural diff correctly ignores.

An array of tables, and an ID that usually gets destroyed

Three things are worth watching. [network] is a single table and becomes one nested object; [[sim]] written twice becomes a JSON array, which is the construct people most often misread. Both iccid values are 19 digits — past what a JavaScript number can hold — and both arrive as bare JSON integers, not quoted strings. The comment is gone, because JSON has nowhere to put it. And note last_run: the milliseconds in the output were not in the source. TOML hands back a real Date, and serialising a Date to JSON always writes them.

config.toml → config.json 19 digits intact

config.tomlTable, array of tables, datetime

# provisioning defaults
name = "subscriber-sync"
last_run = 2026-01-14T09:30:00Z

[network]
mcc = 234
mnc = 15

[[sim]]
msisdn = "447700900142"
iccid = 8901240544102066246

[[sim]]
msisdn = "447700900458"
iccid = 8901240544102066253

config.jsonISO dates · bare 19-digit integers

{
  "name": "subscriber-sync",
  "last_run": "2026-01-14T09:30:00.000Z",
  "network": {
    "mcc": 234,
    "mnc": 15
  },
  "sim": [
    {
      "msisdn": "447700900142",
      "iccid": 8901240544102066246
    },
    {
      "msisdn": "447700900458",
      "iccid": 8901240544102066253
    }
  ]
}

When this is the tool you want

Reading someone else's Rust or Python project

A Cargo.toml with several [[bin]] targets and a wall of dependency tables is much easier to take in as JSON, where the nesting is on the page instead of in your head.

Feeding a config into a script

Most languages read JSON from the standard library and need a package for TOML. Converting once is often quicker than adding a dependency to a throwaway script.

Comparing two environments

Convert both and run them through JSON Diff. Section order and inline-versus-expanded tables stop mattering, so what you see is the difference that actually changes behaviour.

Getting a table out of a config

An array of tables is a table in the spreadsheet sense too. TOML to Table goes there directly, and JSON to CSV takes it further.

What it does

64-bit integers survive. The TOML spec requires it, and most converters break it — a 19-digit ICCID comes out with all 19 digits, as a bare JSON number rather than a quoted string.
Arrays of tables become JSON arrays, so [[bin]] and [[sim]] read the way they behave.
Datetimes come out as ISO 8601, and a local date or local time keeps its missing timezone rather than being padded into a full UTC timestamp with a made-up offset. The seconds field is normalised to milliseconds on the way — 09:30:00 becomes "09:30:00.000" — so the value is the same instant with more digits, not a different one.
Infinity and NaN are named, not hidden. JSON cannot represent either, so they become null — and the page tells you which keys that happened to.
Runs in the browser. A config file with an API token in it never leaves the tab.

Questions people actually ask

Where did my comments go?

JSON has no comment syntax, so there is nowhere to put them. This is the one genuinely lossy part of the conversion, and it is a property of JSON rather than of this page — every TOML to JSON converter drops them. If the comments are the point, keep the TOML.

Why is my big number a string in other converters but not here?

Because they parse it into a JavaScript number first, which holds about 15 digits, and then quote it to avoid showing a wrong value. The digits are already gone by then. This page protects the literal before parsing, so it stays a real JSON number — see the write-up on large numbers in JSON for why that limit exists.

What happens to inf and nan?

TOML has both as float values; RFC 8259 gives JSON neither, so they can only become null. Rather than let that pass silently, the page lists the keys it affected under the output.

My file has a date without a timezone. What do I get?

No timezone, which is the part that matters — TOML distinguishes an offset datetime, a local datetime, a local date and a local time, and the last three deliberately carry no offset. Nothing here invents one, because that would be a guess about a machine you are not on. What you do get is a normalisation of the seconds field: 2026-01-14 stays "2026-01-14", but 09:30:00 comes out as "09:30:00.000" and 2026-01-14T09:30:00Z as "2026-01-14T09:30:00.000Z". The milliseconds are added, not read from your file. That is what a datetime looks like once it has been through a JavaScript Date, and it parses back to the same instant everywhere — but if you are diffing the JSON against a hand-written fixture, that is the difference you will see.

Can I go the other way?

Yes — JSON to TOML. Be aware that a round trip normalises the file: comments go, inline tables expand into sections, and 0xDEADBEEF comes back as decimal. The values are identical; the formatting is not.

Worth reading

TOML v1.0.0 specification – Short enough to read in one sitting, and the array-of-tables section is the one worth reading twice
The pyproject.toml specification – Why every modern Python project has one

TOML to JSON