TOML Converter

Convert between TOML, JSON, and YAML configuration formats with validation and formatting.

Tested tool guide Tested browser tools Checked August 16, 2026

What TOML Converter does, with a checked example

TOML, JSON, and YAML are three ways to write the same nested key-value data, and this page re-renders a document from any one into any other. Paste a configuration file, pick the target format, and the tool parses the input strictly, then emits the equivalent document with fresh formatting. Validation comes first: malformed input fails with an error rather than a guessed conversion. What most users get wrong is expecting a round trip: the conversion is lossy. Comments do not survive, and values with no counterpart in the target format - JSON's null, TOML date-times in JSON, YAML anchors - are dropped, turned into strings, or rejected outright.

Worked example

A concrete input and expected output from the current implementation.

Input

title = "Server config"
enabled = true
replicas = 3
ratio = 0.75
tags = ["web", "api"]

[owner]
name = "Ada"

Expected output

{
  "title": "Server config",
  "enabled": true,
  "replicas": 3,
  "ratio": 0.75,
  "tags": ["web", "api"],
  "owner": {
    "name": "Ada"
  }
}

Every TOML value maps one-to-one onto a JSON value of the same type - booleans stay booleans, numbers stay numbers - and the [owner] table header becomes a nested object. Only presentation changes: quoting, indentation, and blank lines.

How the result is produced

Parse, then emit

The tool first parses the pasted document with a parser for that format, enforcing its rules: TOML's homogeneity and no-duplicate-keys constraints, YAML's indentation and quoting grammar, JSON's exact syntax. Only a fully valid document is converted; malformed input is reported as an error. The parsed result becomes a tree of plain values, and that tree - not the original text - is what gets re-serialized, so comments are lost.

Type mapping

Each value type follows a fixed mapping. TOML tables become JSON objects and YAML mappings; strings, booleans, integers, and floats pass through unchanged. TOML date-times have no JSON type, so they are emitted as ISO-8601 strings. JSON null and YAML null, anchors, and tags cannot be expressed in TOML. Numbers are limited by TOML's 64-bit signed integer and double-precision float ranges, so extreme JSON numbers may not convert exactly.

Good uses

A CI or deployment service wants its config as JSON while the project keeps it as Cargo.toml or pyproject.toml; convert once and paste it in.
The team standard moves from YAML to TOML (or back) for new tooling; convert existing configs instead of hand-rewriting them.
A config copied from a gist, forum post, or another project arrives in a format or style your repo does not use; repaste it into the local standard.

Limits and checks

Every conversion drops comments. JSON has no comment syntax at all, and TOML comments are gone the moment a document becomes JSON or YAML and do not come back on the return trip.
TOML arrays must hold a single data type, so a JSON or YAML array mixing numbers and strings, like [1, "two"], is valid input that cannot be converted to TOML and is rejected.
Under YAML 1.1 rules - which most YAML libraries still implement - bare words yes, no, on, and off parse as booleans, so an unquoted no becomes false rather than the string "no". YAML anchors, tags, and multi-document streams have no JSON or TOML counterpart either.

Common questions

If I convert TOML to JSON and back, will I get my original file?

No. Every comment is lost on the first hop, and values that JSON cannot represent are changed on the way out: a TOML date-time becomes a string and stays a string after the return trip. Tables, numbers, and strings survive; comments and date-times do not. Treat a round trip as a migration, not a backup.

What happens to JSON null when I convert to TOML?

It cannot be represented - TOML has no null value - so that conversion is rejected rather than silently producing a wrong file. The JSON-to-YAML direction is fine, since null is native to both. If you control the source data, replace null with a sentinel such as an empty string or omit the key entirely; TOML's closest equivalent to 'absent' is a key that is not there.

References and verification

The example and behavioral notes were checked against the browser implementation. Standards and primary references below define the relevant format, formula, or platform behavior.