TOML Formatter
Validate and beautify TOML, convert to and from JSON — a helper for Cargo, pyproject and other Rust/Python configs.
>_ USAGE GUIDE
Paste TOML to validate syntax and beautify the layout, with two-way JSON conversion included. TOML is the standard config format for Rust (Cargo.toml), Python (pyproject.toml), and Go tooling — after editing dependency declarations or build settings, validate here first so syntax errors are caught immediately instead of surfacing as a failed build.
- Paste the TOML: a Cargo manifest, pyproject, or any TOML config
- Validate and beautify: errors are located to their line; valid files return tidily formatted
- Convert to JSON: a successful conversion confirms the structure parses as intended
Parsing runs locally with zero uploads, and CJK values keep their original form through conversion. Because the checker runs on every paste, it doubles as a learning tool: edit a table header, watch the structure shift in the JSON output, and the nesting model becomes intuitive within a few tries. Validate before the config enters the project — that is how configuration errors stay out of the build.
>_ FAQ
Q1 · TOML versus YAML and JSON — why did Rust and Python pick it?
TOML is designed for "configuration written by humans": unambiguous syntax (no YAML-style indentation mysticism), friendlier than JSON (comments, multi-line strings, native dates), and highly readable. JSON is built for machine-to-machine data exchange; YAML is expressive but rule-heavy. TOML balances simple, explicit, and sufficient — exactly what a config format needs.
Q2 · What are the common syntax errors in Cargo.toml and pyproject.toml?
The frequent offenders: strings left unquoted (version ranges or paths containing dots and spaces); misspelled or duplicated table headers like [dependencies]; malformed key-value syntax around the equals sign; and inline tables mixed with multi-line tables until ownership gets confusing. Validation here pinpoints the failing line, and a clean JSON conversion confirms the structure parsed correctly.
Q3 · What exactly is a table ([section]) in TOML?
[dependencies] opens a table; every key-value below it belongs to that table until the next header. Dotted headers like [tool.poetry.dependencies] express nesting, and double brackets [[items]] declare an array of tables. The key skill in reading TOML is always knowing which table you are inside — identical key names under different tables never conflict.
Q4 · Does TOML support comments and dates?
Yes, and this is precisely why it beats JSON for configuration: # starts a comment; dates and datetimes are native types (2026-09-07 parses as a date, not a string); triple-quoted multi-line strings hold description text comfortably. JSON offers none of these — which is why JSON moves data and TOML is written by people.
Q5 · My JSON conversion does not match the structure I expected — why?
Mind the nesting rules: [a.b] becomes { "a": { "b": ... } } in JSON, and arrays of tables become JSON arrays. When output looks wrong, the usual cause is a misunderstanding of table ownership. Comparing the JSON hierarchy against the TOML headers one by one is the most direct way to understand how TOML nests.