TOML Formatter
Format, validate and beautify TOML data
About TOML Formatter
TOML Formatter validates and normalizes TOML config files against the TOML 1.0 specification. TOML is designed to be unambiguous — every value has a clear type, indentation is not significant, and the table-based structure maps directly to a hash map. This tool catches syntax errors before you push a bad Cargo.toml to crates.io or break a Hugo site build with a mistyped date.
Common Use Cases
Frequently Asked Questions
Why use TOML over YAML?
TOML does not use indentation for structure, so there are no tabs-vs-spaces errors or indentation drift. Types are explicit — a quoted string is always a string, an integer is always an integer, a date is always a date. YAML's implicit type coercions and indent sensitivity make it error-prone in larger configs. TOML is simpler to parse and reason about.
What is an array of tables?
[[table]] defines an array of table values, equivalent to a JSON array of objects. Each [[dependencies]] block appends one entry to the array. This is how Cargo.toml lists multiple [[example]] or [[bench]] entries, and how Hugo front matter lists multiple [[params.menu]] items.
What are inline tables?
An inline table — {key = "val", other = 1} — puts a whole table on a single line. They are syntactic sugar for simple cases and must fit on one line; they cannot span multiple lines. Use them for short, cohesive values; use regular tables for anything non-trivial.
How does TOML handle dates and times?
TOML has four native temporal types: offset datetime (2024-01-15T09:00:00Z), local datetime (no timezone), local date (2024-01-15), and local time (09:00:00). They follow RFC 3339. No other config format has first-class datetime types; in JSON and YAML you must use strings and hope the consumer parses them correctly.
When is JSON still the better choice?
For machine-to-machine data exchange, JSON wins: it is universally supported in every language, has a simpler spec, and does not require a TOML-specific parser. TOML's advantages — comments, expressive tables, native dates — are most valuable for config files that humans maintain. If the file is generated and consumed by machines, use JSON.