TOML to JSON Converter

What is TOML, and why does it exist alongside YAML?

TOML is a configuration format designed around one goal: being unambiguous. It emerged as a reaction to YAML, where a value's type depends on how it happens to be written and where indentation is structurally significant.

The difference in practice:

That strictness is the whole point. A TOML file cannot have the Norway problem, because NO is not a valid value — you must write "NO" or false, and the file says which you meant.

You will meet it in Cargo.toml (Rust), pyproject.toml (Python), Hugo and Netlify configuration, and .streamlit/config.toml.

How to convert

1. Paste TOML, or switch direction Both ways are supported. JSON to TOML requires an object at the root, since a TOML document is always a table.
2. Read the parse error if there is one TOML errors carry a row and column, and the common causes — a duplicate table, an unquoted value, an unterminated string — are explained in plain language.
3. Check the conversion notes Comments, date types, digit separators and hex literals are each reported when they change.
4. Copy or download Or send the result back to the input to round-trip it and see what survives.

The four date and time types

This is TOML's most distinctive feature and the part JSON handles worst. TOML distinguishes four things that JSON collapses into strings:

The second row is the one that loses meaning. A local date-time deliberately has no time zone: it means "9am wherever this runs", which is what you want for a daily job. Once it is a JSON string, nothing distinguishes it from a timestamp whose zone was simply omitted by mistake. A consumer parsing it with new Date() will apply the local zone and may be hours out.

Each conversion is reported individually so you know which fields need attention on the other side.

Examples: tables, dotted keys and arrays of tables

TOML offers two equivalent ways to write nesting:

# Table header
[owner]
name = "Ada"
email = "ada@example.com"

# Dotted keys — identical result
owner.name = "Ada"
owner.email = "ada@example.com"

Both produce { "owner": { "name": "Ada", "email": "ada@example.com" } }. The distinction is stylistic and does not survive conversion, so converting back gives whichever form the writer prefers.

Array of tables

The double-bracket header is TOML's answer to a list of objects, and it maps cleanly to a JSON array:

[[servers]]
host = "alpha.internal"
port = 8080

[[servers]]
host = "beta.internal"
port = 8081

becomes

{
  "servers": [
    { "host": "alpha.internal", "port": 8080 },
    { "host": "beta.internal", "port": 8081 }
  ]
}

Worth noting: unlike XML, TOML has no one-element ambiguity here. A single [[servers]] block still produces a one-item array, because the double brackets say "this is a list" explicitly. That is the strictness paying off.

Numbers and strings

readable = 1_000_000     →  1000000     (separators removed)
hex      = 0xDEADBEEF    →  3735928559  (converted to decimal)
octal    = 0o755         →  493
binary   = 0b1010        →  10
ratio    = 6.626e-34     →  6.626e-34

basic   = "tab:\t pound:\u00A3"   escapes are processed
literal = 'C:\no\escapes'         single quotes take everything literally

The literal string form is genuinely useful for Windows paths and regular expressions, where a basic string would require doubling every backslash. That distinction is lost in JSON, which has only one string form.

What each direction loses

TOML to JSON

• Comments. JSON has none.
• The four date types collapse into strings, as described above.
• Number notation. 0xFF becomes 255; 1_000 becomes 1000. The values are right, the readability is gone.
• String form. Literal versus basic versus multi-line all become one JSON string type.
• Table style. Whether you used [table] headers or dotted keys is not recorded.
• 64-bit integers. TOML integers are 64-bit; JavaScript is exact only to 2⁵³−1. Larger values are kept as strings to avoid silently changing them.

JSON to TOML

• null has no representation. TOML expresses absence by omitting the key, so a null value is dropped and reported. This is a real semantic difference: JSON can say "this field exists and is empty" and TOML cannot.
• A root array or scalar is invalid. A TOML document must be a table, so [1, 2, 3] at the root has to be wrapped in an object first.
• Mixed-type arrays are accepted by TOML 1.0 but rejected by some parsers, so an array mixing strings and numbers may not load everywhere.

Use cases

• Reading a Cargo.toml or pyproject.toml programmatically. Convert to JSON so ordinary tooling can query it.
• Validating a config against a JSON Schema. Schema tooling works on JSON, so converting first lets you check a TOML file with the JSON Schema Validator.
• Migrating from YAML to TOML. Go YAML to JSON with YAML to JSON, then JSON to TOML here.
• Understanding what your TOML actually parsed to. The JSON view shows real types, revealing that 0o755 became 493 or that a bare date became a local-date object.
• Generating a config from code. Build the structure as JSON, then emit TOML for the tool that expects it.
• Diffing two configs meaningfully. Convert both with keys sorted and compare the JSON, so comment and table-style changes do not appear as differences.

Related config conversions: JSON to YAML, Properties to YAML for Java configuration, and the JSON Formatter to tidy the intermediate output.

Privacy

Parsing and serialising both run in your browser using a spec-compliant TOML parser. The file is not uploaded, which matters because configuration routinely contains internal hostnames and token references. Usage analytics record only the direction, table count and a coarse size band.