📝 TOML ⇔ JSON / YAML Converter

Convert TOML ⇔ JSON and TOML ⇔ YAML in both directions. Ideal for editing Hugo config.toml, Cargo.toml, and pyproject.toml.

100% Free No signup Browser-only 5 languages Dark mode

🔒 About Privacy

・All processing happens entirely in your browser
・Your input data is never sent to any server

Target Format

JSON Indent

Sample

TOML

JSON

Auto-convert

📖 Where people get stuck

Converts TOML to JSON or YAML and back again, which is handy for reading through configuration files such as Cargo.toml, pyproject.toml or a Hugo config.toml. Everything runs in the browser. TOML was designed for configuration files that humans write and read by hand, not as an interchange format — which leaves a few gaps between it and JSON or YAML that cannot be closed.

Case	What happens	What to do
Some JSON values cannot be converted to TOML	TOML has no `null`. That is a specification decision rather than an implementation limit, resting on the view that in a configuration file, no value should be expressed by not writing the key. So `{"timeout": null}` has no TOML representation. For related reasons, arrays of mixed type such as `[1, "two", true]` are rejected by many implementations — TOML 1.0 permits them, but parser support is uneven. Trying to convert an API response directly into TOML runs into these two first.	Strip `null` keys before converting — that is the response consistent with TOML design philosophy. If you want to state the absence explicitly, put in a default that means something for that key, such as an empty string or `false`. Better still, do not use TOML for interchange at all: it is for a different job. TOML suits configuration that people edit by hand and review as a diff, while machine-generated, machine-read data belongs in JSON. If a structure feels awkward to express in TOML, that may be a signal that it is too complex to be configuration — beyond three levels of nesting, the design is worth revisiting.
The output looks different from the hand-written original	TOML can express the same data in three different ways: a table header `[server]`, an array of tables `[[bin]]`, and an inline table `{ host = "x", port = 80 }`. A converter picks one of them, so the output can look nothing like what you wrote by hand even though the structure is identical. The usual source of confusion is that table headers work by position: every key after `[server]` belongs to `server`. Line order carries meaning, so moving a key one line changes which table it belongs to.	Every one of those outputs is valid TOML — if you want it to match the hand-written style, take the conversion as a starting point and tidy it by hand. And do not round-trip an existing configuration file through this tool, for one decisive reason: the comments are lost completely. JSON has no concept of a comment, so reformatting `Cargo.toml` or `pyproject.toml` via JSON throws away the most valuable information in the file, such as why a dependency is pinned. Use this tool to read a file, and make your edits directly in the original.
Dates become strings, or strings become dates	TOML has date and time as first-class types: `created = 1979-05-27T07:32:00Z` is written without quotes and is a datetime value, not a string. JSON has no such type, so conversion turns it into an ISO 8601 string — a natural enough translation. The reverse direction is the problem: converting JSON `"2024-01-01"` back to TOML can, depending on the implementation, drop the quotes and produce a date value, changing the meaning. If you are handling version dates, or identifiers that merely look like dates, such as a release named `"2024-01-01"`, a round trip alone changes the type.	Do not round-trip values that look like dates. Where you have no choice, read the converted TOML and check that the quotes are on the side you intended: `created = 2024-01-01` is a date and `created = "2024-01-01"` is a string, and that one pair of quotes decides the type. To avoid the question at design time, prefix values that must not be dates, as in `"v2024-01-01"`. TOML has three temporal types — local date, local time and offset date-time — and they mean different things; always write the offset on values that need a time zone.

Configuration files carry conventions, not just structure. The keys in pyproject.toml are fixed by PEP 518 and PEP 621, and changing the shape of [project] or [build-system] makes pip install -e . fail. The same holds for Cargo.toml: [[bin]] must be an array of tables, and writing [bin] means something else entirely. So this tool is properly used for reading and understanding a configuration file someone else wrote, not as a route for reformatting or rewriting one. Second, TOML has no anchors or references the way YAML does. You have to repeat a value in several places, which can look redundant, but it is the consequence of a design decision that a configuration file should be understandable read straight down. If you want to factor something out, do not try to solve it inside the TOML — solve it in whatever generates the file.

📖 How to Use

1

Paste TOML

Paste TOML on the left or pick a sample (Hugo / Cargo / pyproject).
2

Pick the target format

Pick JSON or YAML. For JSON, choose 2/4 spaces or minify.
3

Convert both directions

Results appear on the right. Reverse direction (JSON/YAML → TOML) updates live too.

❓ Frequently Asked Questions

What is TOML?

Stands for Tom's Obvious, Minimal Language. INI-like readability with explicit types — widely used in Cargo (Rust), Hugo, and pyproject.toml.

How are dates and times handled?

TOML has datetime / date / time types. They become ISO 8601 strings in JSON and proper YAML types when converting to YAML.

Can I convert YAML or JSON back to TOML?

Yes. Paste JSON or YAML on the right and click → TOML, or keep auto-convert on. Some structures TOML cannot represent (e.g. mixed-type arrays) are skipped.

🔗 Related Tools

🐛 Found a bug or issue with this tool?

Free to use, no signup. Even just the steps to reproduce are helpful. Reports go directly to the operator and help us fix issues.