Convert JSON to TOML for configuration files

Check that the JSON is TOML-shaped

A root object maps naturally to TOML. Nested objects become table headers, and arrays of objects become repeated array-of-table sections. A root array can be wrapped under a root key by the export path, but that may or may not be the shape your application expects.

TOML has no native null. Mixed-type arrays are different: TOML 1.0 allows them, but JSON All-in-One's current exporter checks for matching value types within arrays. A valid TOML shape can therefore still need reshaping for this export path.

Copyable TOML mapping

The example below shows top-level scalars first, then a nested table, then repeated server tables. It uses no nulls and keeps each array's values compatible with the exporter.

{
  "title": "catalog-demo",
  "enabled": true,
  "ports": [80, 443],
  "owner": {"name": "Ann"},
  "servers": [
    {"host": "edge-a", "port": 8080},
    {"host": "edge-b", "port": 8081}
  ]
}

title = "catalog-demo"
enabled = true
ports = [80, 443]

[owner]
name = "Ann"

[[servers]]
host = "edge-a"
port = 8080

[[servers]]
host = "edge-b"
port = 8081

Export TOML

1. Open the JSON configuration locally.
2. Remove or transform values that TOML cannot represent, especially nulls, before export.
3. Choose Export, then TOML.
4. Save the file as .toml and parse it with the receiving project's TOML implementation.
5. Compare the key paths the application expects with the key paths the export produced.

Nulls and mixed arrays need a decision

For {"name": null}, decide what the receiving application expects: an omitted setting, an empty string, or a documented default. Those choices are not interchangeable, so do not replace nulls blindly.

For {"items": [1, "two"]}, the restriction is in the current exporter, not TOML 1.0. You can reshape the data if that suits the receiver, or use a conversion path that supports mixed-type arrays. Do not change the values just to get a file to export.

{"name": null}
{"items": [1, "two"]}

Root arrays become a `root` setting

A JSON array has no table name by itself. Object rows may become repeated [[root]] sections, while scalar arrays may become root = [...]. That behavior is useful as a neutral export shape, but it is not proof that a tool such as Cargo, Poetry, or another application will accept the file.

If the receiver expects a named table like [[servers]], shape the JSON into an object with that key before exporting.

This is the most common place to slow down. A syntactically valid TOML file can still have the wrong key names. If your application reads servers, do not hand it root and hope the names are equivalent.

Parse, then check semantics

A TOML parser check should be the first gate, not the last one. It tells you whether the file is well formed. After that, check the actual object your application receives: are ports numbers, are repeated servers a list, and are quoted keys exactly where the loader expects them?

If a transformation was required to remove nulls or split mixed arrays, document it next to the exported file. That small note prevents a future teammate from assuming the TOML is a lossless representation of the original JSON.

Related guides

Choose YAML when null visibility and readability matter more than TOML strictness. Choose .properties when the receiver wants flat keys. Use the export format hub if you are still choosing the receiving format.

• Convert JSON to YAML
• Convert JSON to .properties
• Compare export formats