TOML to JSON Converter

TOML is written for people and JSON is read by programs, so this conversion is usually a step in a pipeline: a build script that needs to read pyproject.toml from a language with no TOML library, a tool that validates configuration against a JSON Schema, a template that interpolates values from Cargo.toml, or simply a check on what a file actually parses to when the table headers have got confusing.

The interesting parts of the conversion are the two places where TOML is richer than JSON. TOML has first-class date and time types, which JSON does not, and it has comments, which JSON also does not. Both are handled below. Parsing runs in a Web Worker in your browser, so a config file containing a database URL never leaves your machine.

How TOML structures arrive in JSON

• Table headers become nested objects. A [server] section becomes a "server" object, and [server.tls] becomes a "tls" object inside it. The flat, readable header list turns into the tree it always represented.
• Dotted keys become nesting too. A key written pool.size = 20 inside [database] produces "database": {"pool": {"size": 20}}. This catches people out: in TOML the dot inside a bare key is a structural path, not part of the name, so the JSON has an extra level you might not have expected.
• Arrays of tables become arrays of objects. Repeated [[rate-limit]] blocks become a "rate-limit" array with one object per block, in document order.
• Integers and floats are distinguished by TOML and merged by JSON. TOML's 8080 is an integer and 0.05 is a float; JSON has one number type, so the distinction exists in the source and not in the output. Underscore separators in numeric literals, as in 1_048_576, are stripped during parsing and the plain value appears in the JSON.
• All three string forms collapse to one. Basic strings, literal single-quoted strings and multi-line triple-quoted strings all become ordinary JSON strings; the newlines in a multi-line block become \n escapes. Which syntax produced the string is not recorded.
• Hyphenated keys stay hyphenated. per-minute becomes the JSON key "per-minute", which is valid JSON but awkward to access with dot notation in JavaScript. Bracket access or a rename on your side handles it.

Dates and times: the real mismatch

TOML defines four temporal types and treats them as first-class values, which is one of the reasons it exists. An offset date-time 2026-03-11T09:14:02Z, a local date-time without an offset, a local date 2026-06-01, and a local time 22:00:00 are all distinct types in the data model, and a TOML parser hands them to your application as date objects rather than text.

JSON has no date type whatsoever. So every one of these becomes a string in the output, in ISO 8601 form. That is the only representation available, and it is what every JSON API does with timestamps too.

The subtlety worth checking is the offset-less types. A TOML local date deliberately carries no timezone — 2026-06-01 means that calendar day wherever you are, which is the right model for a renewal date or a contract term. Rendering it as an ISO string can attach a UTC representation that implies a precision the original value did not have. If your consumer is timezone-sensitive, inspect those fields in the output and decide whether you want the bare date string instead.

The reverse direction is worse: convert this JSON back to TOML and your dates return as quoted strings, not as TOML datetimes, because by then they are indistinguishable from any other text. Date typing is a one-way loss across this boundary.

Comments, ordering and numeric range

Every # comment is discarded, because JSON has no comment syntax. In a configuration file the comments frequently carry the reasoning — why a pool size is 20, who owns the file, what breaks if a flag is flipped — so keep the TOML as your source of truth and treat the JSON as a generated artefact.

Key order within a table is preserved as written in practice, and arrays of tables keep their document order. But TOML explicitly does not consider key order meaningful, and neither does JSON, so do not build anything that depends on it.

One numeric edge to be aware of: TOML specifies 64-bit signed integers, while JSON numbers are IEEE-754 doubles in every mainstream implementation. Integers beyond roughly nine quadrillion cannot be represented exactly, so a very large identifier written as a TOML integer may not survive the trip with all its digits intact. If you have such values, store them as quoted strings in the TOML.

Everything runs client-side in a Web Worker. Nothing is uploaded, which is the usual consideration when the file you are pasting contains a connection string.