TOML ⇄ JSON in your browser, no signup

TOML exists because JSON is a poor configuration language: no comments, punishing punctuation, and no way to express a nested section without stacking braces. TOML gives you comments, plain key = value lines, and [section] headers that map onto nested objects - which is why Cargo, pyproject.toml, Netlify and Hugo all use it. JSON in turn is what almost every library and script actually reads. Converting between them lets you keep a config readable for humans while feeding it to a tool that only speaks JSON. This converter covers what configuration files actually contain: sections, dotted keys, arrays of tables with [[double brackets]], strings, numbers, booleans, single-line arrays and # comments. It is a compact parser rather than a full TOML implementation - multi-line strings, inline { } tables and native date types are the cases it does not handle, so treat it as a fast converter for ordinary config, not a spec-complete validator. It runs entirely in your browser.

You should not have to open an IDE to format a snippet from Slack, tidy a JSON blob, or check a hash. Paste it here, copy the result, move on.

TOML ⇄ JSON is a good fit when reading a Cargo.toml or pyproject.toml from a script that only parses JSON.

In plain English

TOML ⇄ JSON is built around a few practical wins, not a long feature list:

• Handles the parts of TOML that config files actually use, including dotted keys and arrays of tables.
• Converts both ways, so you can move a JSON config into readable TOML as well.
• Strips comments cleanly rather than choking on them.
• Runs in your browser - config files hold tokens and connection strings, so this matters.
• Instant, with no account or upload.

How to run it

1. Choose the direction. TOML to JSON, or JSON to TOML.
2. Paste your config. A Cargo.toml, pyproject.toml or any key = value file works. Comments are stripped as it parses.
3. Convert and read the output. [section] becomes a nested object, and [[section]] becomes an array of objects.
4. Check anything unusual. Dates, multi-line strings and inline tables are the cases to verify by eye.

Real situations

• Reading a Cargo.toml or pyproject.toml from a script that only parses JSON.
• Migrating an app config from JSON to TOML so it can carry comments.
• Inspecting the structure a TOML file actually produces before writing code against it.
• Converting a config sample for documentation.
• Checking whether [[table]] entries are nesting the way you intended.

Small habits that help

• Convert TOML to JSON to see exactly what nesting your [section] headers produce - this is the fastest way to debug a config that a tool is reading wrongly.
• TOML dates are a native type; JSON has none, so they arrive as strings. Parse them yourself on the other side.
• This parser reads one key = value per line. Rewrite multi-line strings and inline { } tables into ordinary form before converting.
• Remember [[name]] means an array of tables. Getting a list where you expected an object usually means a doubled bracket.
• Never paste a config containing live secrets into a converter that runs server-side. This one does not - but check before you use another.

Skip these

• Expecting full TOML spec support - multi-line strings, inline tables and native dates are outside what this compact parser handles.
• Treating it as a TOML validator. Lines it does not recognise are skipped rather than reported, so a clean-looking result is not proof the file is valid.

Does anything leave your device?

TOML ⇄ JSON runs in your browser. The file or text you paste stays on your device. There is no account, and nothing is stored on a ToolBox server for this job.

Related tools worth opening next

If this is one step in a longer job, these usually come after it:

• YAML ⇄ JSON - Convert between YAML and JSON formats
• JSON Formatter - Format and validate JSON data
• YAML Formatter - Format and validate YAML documents

FAQ

What is TOML used for?

Configuration. Cargo.toml in Rust, pyproject.toml in Python, and the config files for Hugo, Netlify and many others. It is popular because it allows comments and expresses nesting through readable [section] headers rather than nested braces.

Are dates converted correctly?

TOML has a native date and time type; JSON does not. Dates therefore come through as strings, which you parse on the other side. Converting back will not restore them to a native TOML date.

Does it validate my TOML?

No, and it is worth being clear about that. It is a lenient parser: lines it cannot interpret are skipped rather than reported as errors, so a successful conversion is not proof that your file is spec-valid. Use it to convert, and your actual toolchain to validate.

Which TOML features are not supported?

Multi-line basic and literal strings, inline { } tables, and native date types. Everything is read one line at a time, so those constructs need rewriting into plain key = value or [section] form first.

What does [[double brackets]] mean?

An array of tables. Each [[servers]] block appends another object to a servers array, which is how TOML expresses a list of structured entries. Getting an array where you expected an object almost always traces back to this.

Is my config uploaded?

No. Everything is parsed in your browser, which matters because config files routinely contain API keys and database URLs.

Open the TOML ⇄ JSON when you are ready. It is free, and you do not need an account.