TOML Formatter / Validator
Parse, validate and pretty-print TOML documents.
Overview
The TOML formatter parses, validates, and pretty-prints a TOML document. It enforces the TOML 1.0 specification, catches syntax errors with line numbers, and re-emits the source with consistent spacing and section ordering.
TOML is the configuration format used by pyproject.toml, Cargo's Cargo.toml, and many Rust and Python tools. Developers reach for a toml formatter when cleaning up a hand-edited config, validating a generated file, or diff-friendly normalising before committing.
How it works
TOML 1.0, specified at toml.io, defines key-value pairs, tables ([section]), array-of-tables ([[items]]), inline tables, and several scalar types — strings, integers, floats, booleans, datetimes, and arrays. The formatter parses the input against the full spec and reports any error with its location.
Reformatting normalises spacing around =, places blank lines between top-level tables for readability, and emits scalar literals in their canonical form (no leading zeros, exponent normalisation for floats). Arrays of objects ([[items]]) keep their array-of-tables form; inline tables ({ a = 1 }) and single-line arrays stay compact unless they exceed a configurable width.
Examples
Input (messy):
title="My App"
[server]
host = "localhost"
port=8080
[[users]]
name="Alice"
[[users]]
name="Bob"
Output:
title = "My App"
[server]
host = "localhost"
port = 8080
[[users]]
name = "Alice"
[[users]]
name = "Bob"
FAQ
What's the difference between TOML and YAML?
TOML is designed for configuration with obvious semantics — fewer footguns around type coercion (no yes accidentally becoming boolean true), explicit datetime types, and clear array vs. table syntax. YAML is more flexible but easier to misread.
Does it support TOML 1.1 features?
The formatter follows TOML 1.0, which is the current stable spec. TOML 1.1 is still in draft and adds features like newlines in inline tables; those are flagged as warnings when present.
Why doesn't my datetime parse?
TOML datetimes must follow RFC 3339 format: 2024-01-15T10:30:00Z or with offset 2024-01-15T10:30:00-05:00. Local date-times without timezone and local dates are also supported but distinguished by type.