NV ToolkitFormat · Validate · Convert

Converters

TOML to JSON Converter

Parse any TOML document — pyproject.toml, Cargo.toml, wrangler.toml — into clean JSON, with dates kept as ISO strings and 64-bit integers kept exact.

In short

Convert TOML to JSON online with a TOML 1.0 parser: tables, arrays of tables, inline tables and all four date-time kinds mapped, errors with line and column. Free.

By NaveenKumar T · Updated

Learn: TOML vs YAML vs JSON: Choosing a Configuration Format

  • TOML 1.0 (and 1.1) parser
  • Arrays of tables → JSON arrays
  • Dates kept as ISO strings

Runs entirely in your browser — nothing you paste or open here is uploaded, logged, or stored.How we handle data →

Example

TOML to JSON: input and output

A Cargo.toml-style manifest: a [package] table with a local date, an inline table dependency, two array-of-tables binaries, and a 64-bit integer at its exact maximum.

Input · TOML
[package]
name = "shopfront"
version = "0.4.0"
edition = "2021"
released = 2026-09-01

[dependencies]
serde = { version = "1.0", features = ["derive"] }

[[bin]]
name = "server"
path = "src/bin/server.rs"

[[bin]]
name = "worker"
path = "src/bin/worker.rs"

[limits]
max_i64 = 9223372036854775807
Output · JSON
{
  "package": {
    "name": "shopfront",
    "version": "0.4.0",
    "edition": "2021",
    "released": "2026-09-01"
  },
  "dependencies": {
    "serde": {
      "version": "1.0",
      "features": [
        "derive"
      ]
    }
  },
  "bin": [
    {
      "name": "server",
      "path": "src/bin/server.rs"
    },
    {
      "name": "worker",
      "path": "src/bin/worker.rs"
    }
  ],
  "limits": {
    "max_i64": "9223372036854775807"
  }
}

The serde inline table became a nested object identical to what a [dependencies.serde] block would produce, the two [[bin]] tables became a two-element bin array, released kept its date shape as a plain string, and max_i64 came back as the quoted string "9223372036854775807" rather than a JSON number, since it sits past the 2^53 boundary a double can represent exactly.

Learn more

How TOML constructs map to JSON

TOML was designed to be an obvious, minimal-surprises mapping onto the same tree shape JSON already uses, so the conversion is mostly mechanical: a [table] becomes a JSON object, a dotted key (a.b.c = 1) becomes nested objects the same way a bracketed heading would, and a bare array ([1, 2, 3]) becomes a JSON array. The two places TOML syntax varies without changing the resulting shape are inline tables (kept on one line with { }) and arrays of tables ([[name]], repeated to build up a list) — both produce ordinary JSON objects and arrays once parsed, covered in the FAQ above.

Where the two formats genuinely differ is in what TOML can express that JSON cannot represent natively: four separate date/time types (kept as strings here), 64-bit integers (kept exact via a string once they exceed what a JSON number can hold precisely), and TOML's distinction between literal strings ('no escapes') and basic strings ("\n escapes processed") — both string kinds produce the identical JSON string once smol-toml has resolved their content, since by the time a value reaches JSON it's just text.

TOML construct → JSON
TOMLJSON
[table]Object
a.b.c = 1 (dotted key)Nested objects: { "a": { "b": { "c": 1 } } }
Inline table { a = 1 }Object (identical to [table] form)
Array [1, 2, 3]Array
[[array of tables]]Array of objects
Basic / literal stringString
IntegerNumber, or a quoted string above 2^53
FloatNumber
BooleanBoolean
Offset / local date-time, date, timeISO 8601 string

When you convert TOML to JSON

TOML shows up wherever a project wants human-editable configuration with real types and no YAML-style indentation traps: Python's pyproject.toml (PEP 518), Rust's Cargo.toml, Cloudflare's wrangler.toml, Netlify's netlify.toml, and Hugo site configuration all use it as their primary or an accepted format. Converting to JSON is the bridge into the much larger world of JSON-only tooling — piping a manifest through jq, feeding a config into a JSON Schema validator, or loading it into a JavaScript build script that has no TOML parser of its own but reads JSON natively.

For the reverse direction, JSON to TOML turns a JSON object back into TOML tables. To check the TOML file's syntax without converting anything, or to tidy inconsistent formatting, TOML Formatter validates and can normalize the file in place. If TOML, YAML and JSON are all on the table for a new config file, the TOML vs YAML vs JSON guide compares them side by side with a decision table.

Help

Frequently asked questions

Everything you need to know about the TOML to JSON.

01How do I convert TOML to JSON?

Paste your TOML — or click Sample for a small Cargo.toml-style document — and the JSON appears immediately in the output pane. Nothing is uploaded: parsing runs entirely in your browser with the smol-toml library, and a syntax error is reported with its exact line and column instead of a vague failure.

02What happens to TOML dates and times?

TOML has four distinct date/time kinds and this converter keeps all of them as ISO 8601 strings, because JSON has no native date type. An offset date-time (2026-09-18T09:30:00+05:30) keeps its offset; a local date-time (no offset) keeps the same shape without a Z or offset suffix; a local date (2026-09-18) stays just the date; and a local time (09:30:00) stays just the time. None of them become JavaScript Date objects during the conversion — they pass straight through as text, so a downstream JSON.parse never needs to guess a timezone that wasn't in the source.

03Why is a large integer written as a string?

TOML integers are 64-bit and can hold values up to 9,223,372,036,854,775,807, but JSON numbers are IEEE-754 doubles, which only represent integers exactly up to 2^53 (9,007,199,254,740,991) — anything past that boundary loses precision if it's written as a bare JSON number. This converter checks every integer as it converts and writes only the ones that need it as a quoted string, so an ordinary port number or array index stays a plain number while a 64-bit limit like i64::MAX in the example below survives with every digit intact.

04Are inline tables and [[arrays of tables]] different in JSON?

No — both TOML syntaxes collapse to the same JSON shapes once parsed. An inline table like serde = { version = "1.0", features = ["derive"] } and an equivalent [dependencies.serde] block produce an identical JSON object; the syntax is purely a source-file convenience TOML offers so short tables don't need their own [heading]. Likewise [[bin]] (array-of-tables syntax) and a hand-written bin = [{ name = "a" }, { name = "b" }] inline array both become the same JSON array of objects — the converter works from the parsed value, so it never has to know or care which syntax variant produced it.

05Does the converter accept TOML 1.1 features?

Yes — the underlying parser (smol-toml) implements the still-unreleased TOML 1.1 draft, which is a superset of the ratified TOML 1.0 spec, so anything valid in 1.0 parses unchanged. TOML 1.1 additionally permits newlines inside inline tables (spreading a { ... } table across several lines), adds \e and \x escape sequences in strings, and relaxes a few other corners. If the TOML you're converting must stay strictly 1.0-compatible for a consumer that hasn't caught up (some older parsers reject a multi-line inline table), avoid those specific constructs in your source rather than relying on this page to reject them — it won't.

Keep working

Related tools

Learn the format

Related guides

All guides →