TOML Formatter & Validator
Parse, validate, and normalize TOML with a real spec-compliant parser. View it as formatted TOML or JSON.
Paste TOML above to parse it.
About TOML
TOML(Tom's Obvious, Minimal Language) is a configuration file format designed to be easy to read. It maps unambiguously to a hash table and supports strings, integers, floats, booleans, datetimes, arrays, inline tables, and arrays of tables. TOML is used by Rust's Cargo.toml, Python's pyproject.toml, and many other tools. This validator uses a real, spec-compliant parser, so it correctly handles inline tables, dotted keys, multi-line strings/arrays, trailing comments, and 1_000-style numbers — and reports the exact line and column when input is genuinely invalid. Then it re-emits normalized TOML (or JSON) that you can copy or download. Everything runs locally in your browser.
Built and maintained by Meet Shah · Last updated
What this tool is used for
- Normalising indentation in a TOML config someone hand-edited.
- Finding the line where a config stopped parsing.
- Checking how a parser resolved your tables and types.
- Viewing the parsed structure as JSON to confirm intent.
- Tidying a file before committing it so the diff shows intent.
Frequently Asked Questions
- Does TOML have an official style?
- The specification defines syntax, not layout, so there is no formal style guide. Conventions have settled anyway: one space around `=`, no indentation under table headers, and a blank line between tables — which is what Cargo and pyproject files look like in practice.
- Should keys under a table be indented?
- Convention says no, unlike YAML. TOML's structure comes from the `[table]` header rather than from whitespace, so indentation is purely decorative — and indenting it invites the assumption that the whitespace is meaningful, which it is not.
- How should long arrays be formatted?
- One element per line with a trailing comma, which TOML permits. That keeps a diff to a single line when an element is added and makes a long dependency list readable — the same argument as for trailing commas in every other format that allows them.
- Why does key order matter?
- Because every key after a `[table]` header belongs to that table. Top-level keys must appear before the first header, which is a correctness rule rather than a style one — a formatter that reorders keys across a header boundary changes the document's meaning.
- Are comments preserved by formatting?
- They should be, and it is the hardest part to implement — comments are not part of the parsed data structure, so a formatter that parses and re-emits loses them unless it tracks them separately. Losing a comment is the failure mode to check for after formatting.
Common errors and gotchas
- Assuming valid TOML means a valid config, which is a separate question.
- Reordering keys so a table's own keys no longer precede its sub-tables, which TOML requires.
- Expecting comments to survive a reformat, which many formatters drop.
- Overlooking that TOML dates and times are typed values rather than strings.
- Duplicating a key, which TOML forbids outright rather than resolving silently.