TOML Formatter

What this formatter actually changes

This TOML formatter is a whitespace normalizer for line-oriented text. It removes leading and trailing whitespace from each nonempty line, drops blank lines, and rewrites indentation using either two or four spaces when its simple bracket rules indicate nesting. It does not parse TOML, reorder keys, normalize spaces around =, split compressed assignments, or verify syntax.

That precise description matters. A full TOML beautifier understands tables, arrays, strings, comments, and value types. This component treats input as lines. Use it for cleaning inconsistent line indentation in a small snippet, not for repairing malformed TOML or enforcing a repository-wide canonical style.

A short formatting pass

Paste raw code in the left editor and select 2 Spaces or 4 Spaces. The formatted result appears on the right. Empty input clears the output; Copy transfers the displayed text.

Given already line-separated input such as:

   [database]
 server = "192.168.1.1"
 ports = [8001, 8002]
 enabled = true

the tool removes the incidental leading spaces:

[database]
server = "192.168.1.1"
ports = [8001, 8002]
enabled = true

It does not turn [database]server="host"ports=[8001] into several lines. TOML has no universal delimiter that would make that transformation safe, and the implementation never inserts line breaks.

Why the indent selector may appear inactive

Standard TOML tables are marked by [table], but they do not open indentation blocks in the way { opens a block in many programming languages. The formatter increases indentation only when a trimmed line ends with [ or {, or resembles an opening XML tag. A normal table header ends with ], so it does not increase indentation. Most valid conventional TOML therefore looks the same under two- and four-space settings after outer whitespace is removed.

Multiline arrays can trigger the generic bracket heuristic. A line ending in [ increases the depth, and a later line beginning with ] decreases it:

ports = [
  8000,
  8001,
]

Choosing four spaces would indent the members by four. This is textual indentation, not awareness of TOML array syntax or nested inline tables.

Cleaning a review snippet

Imagine a configuration fragment copied from a chat message with uneven left padding and extra empty lines. First make sure every assignment and header already has its own line. Paste it into the formatter, select the indentation width used by the project, and compare input and output. Copy the result into the working file, then run the project’s real TOML parser or test command.

This sequence separates presentation from correctness. The browser tool can make a snippet easier to read, while cargo metadata, a Python TOML loader, or the application’s configuration check establishes whether it is valid. If formatting changes semantic behavior, stop and inspect strings or multiline structures before committing.

Whitespace that can carry meaning

TOML ignores much incidental whitespace, but whitespace inside quoted strings is data. Because the formatter trims only the entire line and does not edit its interior, ordinary spaces inside a quoted value remain. However, TOML multiline strings have nuanced newline and indentation rules. Removing leading spaces from their content lines may change the resulting string.

Blank lines are always omitted. This removes visual grouping between tables and comments. It may be acceptable for a scratch snippet but undesirable in a maintained configuration file where spacing communicates organization. Comments remain as trimmed lines, yet their original indentation disappears.

The tool also removes a final newline by trimming the completed output. Some repositories require POSIX-style files ending in a newline. After copying, let the editor or project formatter restore that convention.

Not a minifier or validator

An online TOML formatter is sometimes expected to fix key="value" into key = "value", sort tables, align comments, or report duplicate keys. This one performs none of those operations. It will display malformed input without an error because no parsing step exists. It can also format JSON-like or XML-like brackets due to its generic indentation logic, but that does not make such text TOML.

No syntax knowledge means it cannot distinguish a bracket in a comment from structural punctuation. A trimmed line beginning with ] lowers indentation, and a line ending with [ raises it, regardless of whether the characters occur in TOML content. Review unusual strings and comments carefully.

Cases to avoid

Do not use this pass blindly on multiline basic strings, multiline literal strings, certificates, scripts embedded in strings, or documents where blank-line grouping is intentional. Avoid treating it as a repair tool for a minified one-line document. Do not use its output as proof that table names, date-times, escape sequences, numeric forms, or duplicate assignments are legal.

For a full project, prefer an ecosystem formatter that parses TOML and has a stable configuration shared by contributors and CI. Parsing enables semantic preservation and useful diagnostics; a shared version prevents formatting churn.

Comparing before and after

A safe manual check focuses on more than visual neatness. Verify that the number and order of nonblank lines remain expected. Examine multiline arrays and any line beginning with a closing bracket. Confirm that comment placement still makes sense after blank lines vanish. Check multiline string payloads byte for byte. Run a TOML parser, then inspect the version-control diff before accepting the change.

If the only differences are unwanted outer indentation and blank-line removal, the tool has done its intended job. If assignments need spacing normalization or sorting, choose a semantic formatter rather than repeatedly hand-editing this output.

Troubleshooting the output

If several assignments remain on one line, split them in the input; the component only iterates existing lines. If changing from two to four spaces does nothing, the text did not trigger an opening-block heuristic, which is normal for standard table headers. If array members become increasingly indented, inspect lines ending with [ or { and ensure closing lines begin with the matching bracket.

If blank lines disappear, that is current behavior, not a rendering fault. If the copied file lacks a terminal newline, add one through the editor. If a multiline value changes, restore the original and use a TOML-aware formatter.

Choosing the right level of tooling

For a documentation example, code-review comment, or small array block, this formatter can provide a quick cleanup entirely within the page. For repository automation, install a parser-backed formatter, pin its version, document its options, and run it in CI. For configuration migration, validate the parsed data before and after formatting. Formatting and conversion are different tasks; neither substitutes for schema validation.

Local browser execution means the component itself does not submit text to a conversion endpoint. Sensitive configuration may still be exposed through browser extensions, clipboard history, screenshots, or an unmanaged device, so respect the same handling policy used for editors.

Version-control review is especially important because dropping blank lines can create a large cosmetic diff. Format only the selected snippet when possible. A narrow diff helps reviewers see actual configuration changes and reduces merge conflicts with contributors editing nearby tables. If the whole repository needs normalization, adopt one parser-backed formatter and apply it in a dedicated change rather than mixing formatting with behavioral edits.

Predict indentation from line endings

You can anticipate the component’s output without treating it as a TOML parser. A retained line is first trimmed, then outdented if it begins with }, ], or a closing tag. After that line is emitted, indentation increases only if it ends with { or [, or matches the component’s opening-tag heuristic. This means a bracket appearing in the middle of a line has no effect, while one at the end of a comment can affect every following line. Before copying a long result, scan those trigger positions specifically; they explain most unexpected indentation cascades and help distinguish formatter behavior from TOML structure.

Formatter questions

Will it pretty-print one-line TOML?

No. It does not discover assignment boundaries or insert newlines. Put each logical line in the input first.

Does it sort keys or tables?

No. Nonblank lines retain their original order.

Why are my blank lines gone?

Empty trimmed lines are skipped by design. Use a parser-backed formatter if preserving visual groups matters.

Is four-space output more valid than two-space output?

Neither width determines TOML validity. The selector only affects generic nested indentation detected by the component.

Can it tell me whether TOML is valid?

No. Run a conforming parser or application validation command after formatting.

Are comments preserved?

Comment text remains, but surrounding indentation and blank-line spacing are normalized or removed. Comments inside multiline content require special caution.