TOML to JSON Converter

Convert TOML to JSON for tooling that only speaks JSON

TOML has become the default configuration format for a generation of developer tooling — Rust's Cargo.toml, Python's pyproject.toml, and the config files for tools like Ruff, Poetry, Hugo and many others. It is deliberately easy to read and write by hand. The problem comes when you need to feed that config into something that expects JSON: a script, an API, a templating step in CI or a quick inspection in a tool that does not understand tables and dotted keys. This converter turns pasted TOML into structured JSON instantly and locally, and converts JSON back to TOML when you are generating config rather than consuming it. Nothing is uploaded, which matters when manifests carry internal package sources or environment details.

How TOML maps onto JSON

The mental model is straightforward once you see it. A [table] header becomes a nested object, and a dotted header like [servers.alpha] nests objects two levels deep. A [[products]] header — an array of tables — becomes a JSON array of objects, which is exactly how you would model a repeated section. Inline tables such as { version = "1.0", features = ["derive"] } become objects on a single line, and arrays map directly to JSON arrays. Crucially, TOML is strongly typed: integers, floats, booleans and strings each convert to their natural JSON counterpart, so you do not get the stringly-typed ambiguity that plagues conversions from formats like XML or CSV.

The lossy corners to watch

Two type mismatches deserve attention. First, dates: TOML has first-class date-times while JSON does not, so they are preserved as strings and you re-parse them downstream. Second, null: JSON has it and TOML does not, so a round trip through TOML cannot carry a true null and represents it as an empty string instead. If your config distinguishes "absent" from "empty", express that by omitting the key rather than nulling it. Comments are also dropped on the way to JSON, since JSON has nowhere to put them — keep the TOML file as your source of truth if the comments matter.

Validate and format the result

Once you have JSON, tidy it with the JSON Formatter and confirm it parses with the JSON Validator before building against it. If the config is a contract other services depend on, capture its shape with the JSON Schema Generator so changes get caught in review. When your stack actually uses YAML for some of its config, the YAML ⇄ JSON Converter covers that leg, and JSON Diff shows exactly what changed between two converted snapshots after a dependency bump.

Generating TOML from JSON

The reverse direction is handy when a script or API hands you JSON that needs to land in a config file. The serialiser groups simple keys at the top of each table, then emits nested tables and arrays of tables with proper headers, so the output reads like config a human would write rather than one long flat blob. Review the result before committing it: deeply nested or mixed-type arrays are valid JSON but have no clean TOML equivalent, and those are the cases where a quick manual tidy pays off.

Further reading

For the bigger picture, TOML vs JSON vs YAML for config files weighs the three formats. If you are new to the syntax, what is TOML is a plain-English tour of tables, arrays of tables and typed values.