TOML

TOML to JSON Converter

Convert TOML 1.1 and JSON with explicit numeric, date and null handling

Data Format
🔒 100% client-side — your data never leaves this page
Maintained by Evan•Updated: September 30, 2026

TOML 1.1 supports nested tables, arrays of tables, multiline strings and mixed arrays. Dates become ISO-style strings, retaining local date/time kinds and the authored offset; fractional precision is truncated to milliseconds; :60 leap seconds are unsupported. JSON-to-TOML requires an object root, rejects null everywhere and writes nested objects as inline tables. Date-looking JSON strings stay strings.

Input ≤2 MiB; output and name mappings each ≤8 MiB; depth ≤128; values ≤100000; keys or generated paths ≤8192 characters; numeric tokens ≤256 characters. Duplicate keys, collisions, negative zero, non-finite numbers, NUL and unpaired Unicode surrogates are rejected. JSON numbers must round-trip to the same decimal value; integers are limited to ±9007199254740991.

Configuration is processed locally in this page without uploading content or saving input drafts. Analytics exclude keys, values and results. After copying or downloading, check the target application’s configuration rules.

About this tool

TOML to JSON supports TOML 1.1 nested tables, dotted keys, arrays of tables, multiline strings, inline tables and mixed arrays. Large integers become exact decimal strings by default; disabling this option rejects them. Non-finite values, negative zero, unsafe floats and impossible calendar dates are rejected. Dates become ISO-style strings that preserve local date/time kinds and authored offsets, with fractional seconds truncated to milliseconds as permitted by TOML. Reverse conversion requires a strict JSON object and rejects null at every depth; nested objects become inline tables and date-looking strings stay strings. Comments and formatting are not preserved, and TOML date/numeric type identity cannot round-trip through JSON strings automatically. Conversion runs locally in the page without uploading configuration, retaining input drafts, or placing keys and values in analytics. Copy and download contain the complete current result; the screen preview is bounded. Input is limited to 2 MiB, depth to 128, values to 100000, keys or generated paths to 8192 characters, and output and name mappings to 8 MiB each. Numeric tokens are limited to 256 characters. NUL and unpaired Unicode surrogates are rejected. Leap-second values with :60 are unsupported by this converter.

Scenario Recipes

01

Move a dated job configuration into a JSON pipeline

Goal: Keep a large job identifier exact and inspect temporal type conversion.

  1. Paste the shown TOML and keep large integers as strings enabled.
  2. Convert and verify id="9007199254740993", when="2024-02-29T07:32:00.123+08:00", and the mixed values array. Note that the last three fractional digits were truncated.
  3. Copy the JSON into JSON-to-TOML mode and inspect the output: id and when remain strings. Restore native TOML types only after checking what the consuming application requires.

Result: Exact large-ID text, a documented millisecond date representation and an explicit review of type changes during the return conversion.

Failure Clinic (Common Pitfalls)

A null field or non-finite TOML number stops conversion

Cause: TOML has no null and JSON cannot preserve NaN or infinity. Silently omitting an object field or converting a numeric value to null changes the configuration.

Fix: Deliberately remove or replace null before JSON-to-TOML conversion. Use an agreed string representation for exceptional numeric data; the tool does not choose a replacement for you.

A date loses submillisecond digits or remains quoted on the return trip

Cause: The parser retains millisecond precision, which TOML permits. JSON has no date or BigInt type, so those values become strings and reverse conversion has no reliable type tag.

Fix: Keep the original TOML when exact temporal spelling or native types matter. Review the source schema before restoring typed values; mixed arrays are valid TOML and should not be removed merely because their element types differ.

Production Snippets

Large integer and offset date conversion

text

TOML:
id = 9007199254740993
when = 2024-02-29T07:32:00.123456+08:00
values = [1, "two", true]

JSON:
{"id":"9007199254740993","when":"2024-02-29T07:32:00.123+08:00","values":[1,"two",true]}

JSON-to-TOML result:
"id" = "9007199254740993"
"when" = "2024-02-29T07:32:00.123+08:00"
"values" = [1, "two", true]

Frequently Asked Questions

Does it retain TOML 1.1 features and mixed arrays?

Yes. It supports nested tables, arrays of tables, dotted and quoted keys, multiline strings, multiline inline tables, short local times and TOML 1.1 escapes. Mixed arrays are valid; a TOML 1.0 reader may reject 1.1-only syntax.

How are dates and fractional seconds represented?

Dates and times become ISO-style JSON strings. Local dates remain date-only, local times remain time-only, local datetimes have no offset, and offset datetimes retain the authored offset. Invalid calendar dates are rejected. Fractions beyond milliseconds are truncated, which TOML permits; original fractional precision and TOML type tags are not retained. Leap-second values with :60 are unsupported.

How are large integers, decimals, infinity and NaN handled?

Large TOML integers become exact decimal strings by default, or errors when that option is disabled. JSON numeric output must round-trip to the same decimal value and use safe integers. NaN, infinity, negative zero, rounding, overflow and underflow are errors. Numeric tokens are limited to 256 characters; quote high-precision decimal data deliberately.

Can I convert any JSON into TOML?

The root must be an object. Duplicate decoded keys and unsafe numbers are rejected before conversion. TOML has no null, so null is rejected in objects and arrays at every depth. Empty objects and arrays, mixed arrays and special keys are supported; an empty root object produces a valid empty TOML document.

Does converting JSON back restore dates, integer types or comments?

No. JSON strings remain TOML strings, including date-looking strings and decimal strings from large integers. Nested objects are emitted as inline tables. Comments, source layout and original numeric spelling are not reconstructed; review the receiving application’s expected types.

Does conversion store or upload configuration, and what are the limits?

Conversion runs locally in the page without uploading configuration, retaining input drafts, or placing keys and values in analytics. Copy and download contain the complete current result; the screen preview is bounded. Input is limited to 2 MiB, depth to 128, values to 100000, keys or generated paths to 8192 characters, and output and name mappings to 8 MiB each. Numeric tokens are limited to 256 characters. NUL and unpaired Unicode surrogates are rejected.

Keep browsing