TOML to JSON

TOML is designed to be edited by people: section headers, comments, multi-line strings, dotted keys. JSON is designed to be consumed by machines: arrays and objects only, no comments, strictly quoted keys. Converting TOML to JSON is the moment a human-friendly configuration file leaves the human side of the workflow and starts feeding tools that only speak JSON — validators, APIs, debugging consoles, schema generators, or whatever language runtime is going to act on it.

What changes in form, what stays in meaning

After conversion the file looks very different — comments, blank lines, section headers, and dotted keys are all gone. What must survive is the structure: every table becomes an object, every value keeps its type, and every key is reachable by the same logical path the TOML author intended.

How TOML constructs map onto JSON

TOML and JSON share most basic types but spell them differently. Knowing the mapping makes it much easier to predict the output shape before running the converter and to spot something off afterwards.

• Tables ([server], [database.primary]) become nested JSON objects, with each dot in the path adding a level of nesting.
• Array of tables ([[entries]]) becomes a JSON array of objects under the same key.
• Inline tables and arrays follow the closest JSON-style syntax and convert almost one-to-one.
• Integers, floats, booleans, and strings keep their types; multi-line and literal strings flatten into ordinary JSON strings with the same value.
• TOML dates and times become strings in JSON, because JSON has no native date type — and that is fine as long as consumers know to parse them.
• Comments and blank lines have no JSON equivalent and are dropped — they are part of the source file, not part of the data.

Rule of thumb: ask yourself which TOML construct you used to express each piece of intent, then check that the corresponding JSON shape carries that intent without ambiguity.

How to use this tool

1. Prepare representative TOML config files that need JSON for APIs, parsers, or review tools in TOML to JSON instead of starting with the largest or most sensitive real input.
2. Run the workflow, generate JSON text that mirrors TOML tables and values, and review tables, arrays, booleans, strings, nested sections, and whether comments or formatting carried meaning in the original file before deciding the result is ready.
3. Only copy or download the result after it fits config migration, parser input, API payload prep, and tooling review and no longer conflicts with this constraint: TOML comments and formatting intent do not survive conversion, so focus your review on data structure rather than file layout.

TOML to JSON example

This TOML to JSON example uses representative TOML config files that need JSON for APIs, parsers, or review tools and shows the resulting JSON text that mirrors TOML tables and values, so you can confirm tables, arrays, booleans, strings, nested sections, and whether comments or formatting carried meaning in the original file before applying the same settings to real input.

Sample input

title = "ToolKit Online"
draft = false

Expected output

{
  "title": "ToolKit Online",
  "draft": false
}

A small TOML file with its JSON equivalent

# TOML
title = "Sample"
enabled = true

[server]
host = "localhost"
port = 8080

[database.primary]
url = "postgres://localhost/app"
pool = 20

[[entries]]
name = "alpha"
weight = 1.5

[[entries]]
name = "beta"
weight = 2.0

# JSON
{
  "title": "Sample",
  "enabled": true,
  "server": { "host": "localhost", "port": 8080 },
  "database": { "primary": { "url": "postgres://localhost/app", "pool": 20 } },
  "entries": [
    { "name": "alpha", "weight": 1.5 },
    { "name": "beta", "weight": 2.0 }
  ]
}

When TOML → JSON is the right step

TOML stays the source of truth for humans, but JSON is what most automation expects. Conversion is the bridge whenever the two audiences need to share the same data.

• Feeding configuration into an HTTP API or schema validator that only accepts JSON.
• Inspecting a complex TOML file by exploring the converted JSON in a browser DevTools tree, which is often faster than scrolling the original.
• Generating an initial JSON Schema (draft-07) from an existing TOML configuration to lock down expected shape.
• Embedding configuration into a frontend bundle when the runtime cannot pull in a TOML parser.
• Sharing snapshots of a configuration with someone whose tooling only understands JSON (linters, online formatters, scripting languages without a TOML library).

Edge cases worth checking after a TOML → JSON pass

TOML and JSON agree on most things but disagree on a handful that matters in production. Checking these before trusting the converted output saves a lot of debugging later.

• Comments and blank lines are gone. If the config relied on a comment as documentation, move it into a separate README or a description key before converting.
• Dates/times become strings. Consumers must parse them explicitly; do not assume Date.parse will behave the same way across runtimes.
• Numbers: TOML allows large integers and explicit hex/oct/bin notation. JSON only has one number type — confirm precision is still safe after the round trip.
• Dotted keys with the same prefix can collide if also defined as inline tables — the converter should error, not silently merge.
• Array of tables vs inline table arrays look similar but mean subtly different things — verify the JSON shape matches what the consumer expects.

TOML and JSON, compared on what each does best

Practical Notes

• Review tables, arrays, booleans, strings, nested sections, and whether comments or formatting carried meaning in the original file before you reuse the JSON text that mirrors TOML tables and values.
• TOML comments and formatting intent do not survive conversion, so focus your review on data structure rather than file layout.
• Keep the original TOML config files that need JSON for APIs, parsers, or review tools available when the result affects production work or customer-visible content.

TOML to JSON reference

TOML to JSON reference content should stay anchored to TOML config files that need JSON for APIs, parsers, or review tools, the generated JSON text that mirrors TOML tables and values, and the checks needed before config migration, parser input, API payload prep, and tooling review.

• Input focus: TOML config files that need JSON for APIs, parsers, or review tools.
• Output focus: JSON text that mirrors TOML tables and values.
• Review focus: tables, arrays, booleans, strings, nested sections, and whether comments or formatting carried meaning in the original file.

References

• RFC 8259: The JavaScript Object Notation (JSON) Data Interchange Format
• ECMA-404: The JSON Data Interchange Syntax
• TOML v1.0.0