TOML ⇆ JSON converter.

Worked example

The default input above is a small server config. Converted with 2-space indent it becomes:

{
  "title": "TOML example",
  "owner": {
    "name": "Tom Preston-Werner",
    "dob": "1979-05-27T07:32:00-08:00"
  },
  "database": {
    "ports": [
      8000,
      8001,
      8002
    ],
    "temp_targets": {
      "cpu": 79.5,
      "case": 72
    },
    "max_id": 9223372036854775807,
    "mask": 255
  },
  "servers": [
    {
      "name": "alpha",
      "ip": "10.0.0.1"
    },
    {
      "name": "beta",
      "ip": "10.0.0.2"
    }
  ]
}

Things to notice: each [[servers]] header appends one table to a servers array; 0xFF becomes 255; 72.0 becomes 72 because JSON does not distinguish integers from floats; the datetime becomes a string; and max_id is kept as exact digits and flagged, see below.

Datetimes and big integers are not native JSON

TOML has four datetime types: offset date-time, local date-time, local date and local time. JSON has none, so each one is written as an ISO 8601 / RFC 3339 string exactly as TOML spells it (a space between date and time is replaced by T). The type distinction is lost: 1979-05-27 and "1979-05-27" look the same in JSON. Converting back, JSON strings stay strings, so dates do not return as TOML datetimes.

TOML integers are 64-bit signed (−2⁶³ to 2⁶³−1). The JSON format itself allows any digits, but JavaScript’s JSON.parse and most other tools read numbers as 64-bit floats, which are exact only up to 2⁵³−1 (9007199254740991). This tool writes larger integers as exact digits and shows a warning; whatever reads the JSON next may round them. If that matters, convert such values to strings first. TOML inf and nan floats have no JSON form and are written as the strings "inf", "-inf" and "nan".

What it accepts and rejects

The parser follows the TOML v1.0.0 specification and its ABNF grammar. It rejects duplicate keys, redefined tables, tables defined by both a dotted key and a header, appending to inline tables or static arrays, leading zeros, bad underscores in numbers, impossible dates such as 2021-02-29, escapes that are not in 1.0.0 (including \e, which arrived in TOML 1.1), and integers outside the 64-bit range. Mixed-type arrays are fine, as v1.0.0 allows. Each error reports a 1-based line and column.

JSON → TOML: the top level must be an object. A JSON null is an error because TOML has no null. Arrays of objects become [[array of tables]], other arrays stay inline, whole numbers are written as integers and the rest as floats (1.0 in JSON is indistinguishable from 1 once parsed). Comments, key order tricks and formatting in the original TOML are not preserved in either direction.

FAQ

Is my file uploaded?

No. The parser is plain JavaScript on this page and makes no network request with your data.

Why did 72.0 become 72?

JSON has one number type. The value is the same; a reader that needs it as a float has to know from the schema.

Does it do TOML 1.1?

No. It implements v1.0.0 only, so 1.1 additions such as \e escapes, optional seconds in times and newlines in inline tables are reported as errors.

Does a successful parse mean my config is correct?

It means the text is valid TOML. Whether the keys and values suit Cargo, pip or your own app is a separate question this tool does not check.