Validateur et Formateur TOML
Validez et formatez les documents TOML avec traitement local
What is TOML?
TOML (Tom's Obvious Minimal Language) is a configuration file format designed to be easy to read and write due to its clear, minimal semantics. Created by Tom Preston-Werner (co-founder of GitHub), TOML maps unambiguously to a hash table and is intended to be parsed into data structures across a wide variety of languages. Unlike JSON, which was designed for data interchange between machines, or YAML, which prioritizes human readability at the cost of complexity, TOML occupies a deliberate middle ground: it is simple enough for humans to author by hand yet strict enough that parsers can implement it without ambiguity. The TOML specification reached version 1.0 in January 2021, establishing a stable foundation for tooling and library support across all major programming languages.
This tool validates TOML documents against the official specification, reports syntax errors with
precise line and column information, and formats valid TOML into a consistent, readable style.
Whether you are editing a Cargo.toml for Rust, a pyproject.toml for Python,
or a Hugo site configuration, this validator ensures your file conforms to the spec before deployment.
TOML Syntax: Core Data Types and Structures
TOML defines a rich set of native data types that map directly to common programming language
constructs. Strings support four forms: basic (double-quoted with escape sequences), multi-line
basic (triple double-quoted), literal (single-quoted, no escaping), and multi-line literal
(triple single-quoted). Integers support decimal, hexadecimal (0x), octal (0o),
and binary (0b) notation, with optional underscores as visual separators
(e.g., 1_000_000). Floats follow IEEE 754 double precision and support
inf and nan as special values.
Tables are the primary structuring mechanism in TOML, defined by headers enclosed in square brackets.
A table header like [database] creates a named hash map that groups related key-value
pairs. Dotted keys allow nested access without explicit table headers: server.host = "localhost"
is equivalent to defining a [server] table with a host key. Arrays of tables
use double brackets ([[products]]) to define repeated structured entries — a pattern
heavily used in Cargo.toml for specifying multiple dependencies or build targets.
Inline tables provide compact syntax for small groupings: point = { x = 1, y = 2 }.
Unlike standard tables, inline tables must appear on a single line and cannot be extended after
definition. TOML also natively supports RFC 3339 datetime values, including offset date-times
(2024-01-15T10:30:00Z), local date-times, local dates, and local times — a feature
absent from both JSON and YAML without custom extensions.
TOML vs YAML vs JSON: Choosing the Right Format
Each configuration format serves a different design philosophy. JSON excels at machine-to-machine
data interchange: it is universally supported, strictly defined by RFC 8259, and trivial to parse.
However, JSON lacks comments, requires quoting all keys, and uses verbose syntax for nested
structures — making it awkward for hand-edited configuration files. YAML prioritizes human
readability with its indentation-based structure, but this introduces significant complexity:
implicit type coercion (the infamous Norway problem where NO becomes
boolean false), significant whitespace sensitivity, and multiple ways to express the same structure
(flow vs block style) create subtle bugs in production configurations.
TOML avoids both extremes. It requires explicit typing (no implicit coercion), uses unambiguous
syntax (no significant whitespace), supports comments (with #), and provides native
datetime support. The trade-off is that TOML is less suitable for deeply nested hierarchies —
documents with more than 3-4 levels of nesting become harder to read than their YAML equivalents.
For configuration files, which typically have shallow structures with well-defined schemas, TOML
is an excellent fit.
| Feature | TOML | YAML | JSON |
|---|---|---|---|
| Comments | Yes (#) | Yes (#) | No |
| Native datetimes | Yes (RFC 3339) | Partial | No |
| Implicit type coercion | No | Yes | No |
| Multi-line strings | Yes (4 forms) | Yes | No |
| Deep nesting | Awkward | Natural | Verbose |
| Trailing commas | Allowed (arrays) | N/A | No |
Common Use Cases and Ecosystem
TOML has become the standard configuration format for several major ecosystems. In Rust,
Cargo.toml defines package metadata, dependencies, build profiles, and workspace
configuration. In Python, pyproject.toml (defined in PEP 518 and PEP 621) has
replaced setup.py and setup.cfg as the standard project configuration
file, used by tools like pip, poetry, flit, and hatch. Hugo, the popular static site generator
written in Go, supports TOML as its primary configuration format. The Go module system also uses
TOML-inspired syntax in go.sum and related files.
Other notable adopters include Deno (for deno.json alternatives), Pipenv
(Pipfile uses TOML), Black (the Python formatter), and numerous CI/CD systems.
The format's deterministic parsing guarantees make it ideal for configuration that must behave
identically across different tools and platforms — a property that YAML's complex specification
cannot always guarantee.
Validation Rules and Common Errors
TOML validation goes beyond basic syntax checking. A conformant validator enforces several semantic rules: table headers cannot be defined more than once, keys within a table must be unique, inline tables cannot be extended after their initial definition, and arrays of tables must not conflict with static table definitions. These rules prevent ambiguous configurations that could be interpreted differently by different parsers.
Common errors encountered when writing TOML files include: using tabs for indentation in
multi-line basic strings (tabs are allowed only at the beginning of lines in multi-line
literal strings), forgetting that bare keys can only contain ASCII letters, digits, dashes,
and underscores (keys with spaces or special characters must be quoted), attempting to add
keys to an inline table after its definition, mixing array-of-tables syntax with regular
table syntax for the same path, and using invalid datetime formats (TOML requires strict
RFC 3339 compliance — no short forms like 2024-1-5).
This tool reports validation errors with precise line numbers, column positions, and contextual suggestions to help you fix issues quickly. The formatter normalizes whitespace, aligns values within tables for readability, and orders sections consistently.
Code Examples
A complete Cargo.toml configuration for a Rust project
# Package metadata
[package]
name = "my-web-server"
version = "0.3.1"
edition = "2021"
authors = ["Alice <alice@example.com>"]
description = "A fast, lightweight HTTP server"
license = "MIT OR Apache-2.0"
repository = "https://github.com/alice/my-web-server"
# Dependencies with version constraints
[dependencies]
tokio = { version = "1.35", features = ["full"] }
axum = "0.7"
serde = { version = "1.0", features = ["derive"] }
serde_json = "1.0"
tracing = "0.1"
tracing-subscriber = { version = "0.3", features = ["env-filter"] }
[dev-dependencies]
reqwest = { version = "0.11", features = ["json"] }
tokio-test = "0.4"
# Build profiles
[profile.release]
opt-level = 3
lto = true
strip = true
codegen-units = 1
# Binary targets
[[bin]]
name = "server"
path = "src/main.rs"
[[bin]]
name = "cli"
path = "src/cli.rs"A pyproject.toml for a Python library with Poetry
[project]
name = "data-pipeline"
version = "2.1.0"
description = "ETL pipeline for processing analytics events"
requires-python = ">=3.11"
license = { text = "MIT" }
authors = [
{ name = "Bob", email = "bob@example.com" },
]
[project.optional-dependencies]
dev = ["pytest>=7.0", "ruff>=0.1.0", "mypy>=1.5"]
docs = ["sphinx>=7.0", "furo"]
[tool.ruff]
line-length = 100
target-version = "py311"
[tool.ruff.lint]
select = ["E", "F", "I", "N", "W"]
[tool.pytest.ini_options]
testpaths = ["tests"]
addopts = "-v --tb=short"
[build-system]
requires = ["hatchling>=1.18"]
build-backend = "hatchling.build"Standards & Specifications
- TOML Specification v1.0.0 — The official TOML language specification defining all syntax rules, data types, and parsing behavior
- RFC 3339 (Date and Time on the Internet) — The datetime format standard used by TOML for all date and time values
Questions Fréquentes
What does the TOML validator check?
It parses the document and confirms the TOML syntax is valid. If parsing fails, you get a location-aware error message when the parser provides it.
What does formatting do?
Formatting normalizes the TOML structure into a stable output with predictable spacing, section ordering, and consistent quoting.
Can it convert TOML to JSON?
Yes. The page includes a conversion path to JSON so you can inspect the parsed structure in a more familiar shape.
Does it preserve comments?
No. This formatter prioritizes clean output over comment preservation. If you need comment round-tripping, TOML is not your friend today.