Formatters
TOML Formatter & Validator
Validate TOML with exact error positions and your comments intact, or normalize it into a canonical layout — the two are deliberately different modes.
In short
Validate TOML online with exact line and column errors, or normalize it into a canonical layout with sorted keys — pyproject.toml, Cargo.toml, wrangler.toml. Free.
By NaveenKumar T · Updated
Learn: TOML vs YAML vs JSON: Choosing a Configuration Format
- Validate mode keeps your file byte-for-byte
- Normalize mode: canonical tables, optional A→Z keys
- Exact error line & column
Runs entirely in your browser — nothing you paste or open here is uploaded, logged, or stored.How we handle data →
Example
TOML Formatter: input and output
A messy pyproject.toml-style file: trailing spaces, tables written out of the order a human would group them, a dotted key followed by its own [server] block, and an inline table — normalized with alphabetical key sorting.
[tool.ruff]
line-length = 100
server.port = 8080
[server]
host = "0.0.0.0"
[project]
name = "shopfront"
dependencies = [ "fastapi", "uvicorn" ]
urls = { repo = "https://example.com/repo" }[project]
dependencies = [ "fastapi", "uvicorn" ]
name = "shopfront"
[project.urls]
repo = "https://example.com/repo"
[server]
host = "0.0.0.0"
[tool.ruff]
line-length = 100
[tool.ruff.server]
port = 8080
The dotted server.port = 8080 line and the separate [server] block for host both belong to the same table, so normalizing merges them into one canonical [server] block; every table's keys are re-sorted alphabetically (dependencies before name before urls under [project]), trailing whitespace disappears, and — because this is Normalize mode — there is no comment in the input to preserve, but there would not have been one in the output either way.
Learn more
Validate first, normalize when you mean it
Most of the time, what you actually want from a TOML formatter is confirmation that a file is correct — that's Validate mode, and it's the default here for exactly that reason: it changes nothing about your file, so running it is completely safe on a file with carefully hand-placed comments and blank lines you don't want disturbed. Normalize is the mode for machine-generated or messy TOML where a consistent canonical layout matters more than preserving the exact source text — think a config file assembled by a script, or a file you're about to commit and want in the project's standard style.
The trade-off is comments: no TOML parsing library, this site's included, keeps comments as part of the value it hands back, so there is genuinely no way to re-serialize a document AND keep its comments — Normalize mode's label says "drops comments" rather than hiding that limitation.
The TOML errors this catches
A sample of what Validate mode's line/column output actually looks like against real mistakes, all of which are illegal under the TOML 1.0 specification and rejected by every conforming parser, not just this one.
| Mistake | Example line | What happens |
|---|---|---|
| Duplicate key in one table | name = "a"\nname = "b" | Error: key already defined, at the second line |
| Table redefined | [a]\nx = 1\n[a]\ny = 2 | Error: table [a] already defined |
| Unterminated string | name = "unclosed | Error: unterminated string, at end of line |
| Bad inline table trailing comma (1.0) | { a = 1, } | Error, unless the parser's 1.1 leniency accepts it |
| Mixed dotted key and table conflict | a.b = 1\n[a]\nb = 2 | Error: key 'b' already defined |
Formatting TOML for pyproject, Cargo and wrangler
pyproject.toml, Cargo.toml and wrangler.toml each carry their own conventions worth respecting even after this tool confirms the syntax is valid: Cargo's own formatter (and most published crates) tends to group [package] metadata first, dependencies next, and keeps [[bin]]/[[example]] blocks near the bottom; pyproject.toml commonly groups [project], [build-system] and tool-specific tables like [tool.ruff] or [tool.pytest.ini_options] in that rough order; wrangler.toml keeps top-level binding keys near the top with [[kv_namespaces]], [[r2_buckets]] and similar array-of-tables blocks following. Normalize mode's alphabetical-sort option is useful for spotting duplicate or near-duplicate keys, but it will NOT preserve any of those ecosystem conventions — for a file you intend to commit into one of those projects, validate here, then order tables by hand to match the tool's own convention.
For a wider comparison of when TOML is the right choice for a new config file at all, see TOML vs YAML vs JSON. To move data between TOML and JSON rather than just checking syntax, use TOML to JSON and JSON to TOML.
Help
Frequently asked questions
Everything you need to know about the TOML Formatter.
01How do I use this TOML formatter?
Paste or upload a .toml file and pick a mode. Validate (the default) parses the file and reports success or the exact position of the first error, returning your input completely unchanged so nothing about the file's layout or comments is touched. Normalize actually rewrites the file — re-serializing it from the parsed structure into a consistent layout, and optionally sorting keys alphabetically.
02Does formatting keep my comments?
Only in Validate mode, because Validate never rewrites anything — it parses the file to confirm it's syntactically correct TOML and then returns your original text byte-for-byte, comments, blank lines, key order and all. Normalize mode is a genuine re-serialization from the parsed value, and no TOML library — smol-toml included — tracks comments as part of that parsed structure, so Normalize necessarily drops them; the option label says so directly rather than leaving it as a surprise. If your file's comments matter, use Validate to confirm it's correct and leave the layout exactly as you wrote it.
03Is this also a TOML validator and linter?
Yes — Validate mode IS the validator: a file that comes back unchanged with a green "Valid TOML" status parsed without error, and one that fails shows the exact line and column of the first problem. "Lint" here means what the parser itself catches as it goes: duplicate keys, a table redefined after it was already closed, mixing a dotted key with a bracketed table for the same path, and outright syntax errors like an unterminated string or a bad date. It does not mean STYLE rules — there's no opinion enforced here about key ordering, blank lines between tables, or quote style; Normalize mode picks one canonical layout, but nothing warns you about deviating from a house style beyond that.
04What does Normalize change?
It re-serializes the parsed document from scratch: tables are written out in the order their keys were first encountered (or alphabetically, with the Sort option on), dotted keys expand into their table form, and small tables that fit inline may be written as inline tables — whatever smol-toml's own stringifier considers canonical, which is deliberately opinionated rather than configurable. The DATA is unaffected — a normalized file parses back to the identical values — but the exact bytes, comments, and blank-line layout are not preserved, which is the trade this mode makes for a consistent, machine-written style.
05Which errors does it catch that my app's TOML loader reports differently?
The same class of errors every conforming TOML 1.0 parser has to catch, since it's a fully specified grammar with no room for a loader to be more lenient: duplicate keys in the same table, redefining a table that was already closed ([a] appearing twice), mixing dotted-key and bracketed-table syntax for a path that conflicts (a.b = 1 alongside a later [a] block that also tries to define b), unterminated strings, and malformed dates or numbers. What differs between loaders is usually the MESSAGE wording and whether the line/column is reported at all — smol-toml reports both precisely, which is why this page can point at the exact character rather than just saying "parse error."
Keep working
Related tools
TOML to JSON
Parse any TOML document — pyproject.toml, Cargo.toml, wrangler.toml — into clean JSON, with dates kept as ISO strings and 64-bit integers kept exact.
JSON to TOML
Turn a JSON object into well-formed TOML — tables from nested objects, [[tables]] from arrays of objects, and an honest report of what a null cost you.
YAML Formatter
Normalize any YAML to clean, consistent style — uniform indentation, canonical quoting, validation built in.
YAML Validator
Full YAML 1.2 validation with the exact line and column of every error — catch the indent bug before your pipeline does.
C# Formatter
Formatters
Java Formatter
Formatters