TOML Formatter

How the TOML formatter rewrites a file

This TOML formatter parses your document and writes it back out in a single consistent style. Spacing around = is normalized, arrays get uniform spacing, and each table header is separated from the previous section by a blank line. Because the output is generated from the parsed data, it is always valid TOML with the same values as the input, with one exception: fractional seconds are cut to milliseconds.

Example

title="inventory"
version  =   "2.4.1"
[database]
host="db.internal"
ports=[5432,5433]
[[servers]]
name="alpha"
[[servers]]
name="beta"

After Format:

title = "inventory"
version = "2.4.1"

[database]
host = "db.internal"
ports = [ 5432, 5433 ]

[[servers]]
name = "alpha"

[[servers]]
name = "beta"

Important: what reformatting changes

The formatter works from the parsed data rather than the original text. That gives predictable output, but some things are not carried over:

• Comments are removed. TOML parsers discard comments, so a file full of explanatory # lines comes back without them. Keep a copy of the original, or use this tool on generated files where comments do not matter.
• Dotted keys and inline tables become sections. a.b.c = 1 is written as a [a.b] table containing c = 1, and inline = { x = 1 } becomes an [inline] section.
• Plain values come first. Within each table, simple values are written before sub-tables; otherwise the original key order is kept.
• String, number and time notation is normalized. Literal strings such as 'C:\path' and multi-line strings are written as double-quoted strings with escapes, and a time like 07:32:00 gains milliseconds (07:32:00.000). Hexadecimal, octal and binary integers are written in decimal, so 0xFF becomes 255. The values are identical, except that a time with more than three decimal places of seconds is cut to milliseconds: 07:32:00.123456 becomes 07:32:00.123.

The style the output follows

The TOML specification leaves layout largely up to you, but most projects converge on the same conventions, and the formatter applies them:

1. One space on each side of =.
2. Keys written flush left, with no indentation under table headers.
3. A blank line before every [table] and [[array]] header so sections are easy to spot.
4. Arrays on one line with a space after each comma and inside the brackets.
5. Keys quoted only when they contain characters that bare keys cannot.

Since there is only one output style, the result is the same no matter how the input was written. That makes the formatter useful for generated files: run each version through it and differences in whitespace disappear from your reviews.

When to use it

• Cleaning up TOML produced by scripts or copied from several sources before committing it.
• Normalizing a file so that a later diff shows only real changes.
• Checking what a hand-written file really contains: if a key lands in an unexpected table in the output, the original had a structural mistake.

Errors are reported, not guessed

If the input is not valid TOML, nothing is rewritten. You get the parser message and position instead, for example Invalid TOML: trying to redefine an already defined table or value (line 3, column 2). The TOML validator shows the parsed data as JSON, which helps with harder cases.

Working with YAML instead? The YAML formatter keeps comments while it formats.

Privacy

Formatting happens entirely in your browser. Only the optional Load URL (fetched through our server) and Save & Share (stored to create a link) send content to the server.