TOML Format & Validate

Details and how to verify this yourself: Security & privacy.

The studio works like a desktop window: a menu bar (File, Edit, View, Settings, Help) with the full-screen icon at the right of the same row. Settings → Options… opens the options in an overlay (or View → Inline config shows them in the card), and Help → Keyboard shortcuts… lists the keys.

1. Paste or type TOML in the Input view, or choose File → Load sample to start from an example. The editor numbers its lines, and the document is checked as you type.
2. Read the verdict. The Problems view (the button at the right of the status line, which shows the count) lists every finding with its line, column, rule and a short explanation. Errors make the document invalid; warnings and notes are about style. Click a finding to jump to that spot in the input.
3. Choose Edit → Format (or press Ctrl+Enter). The Formatted view shows the canonical layout; Use as input copies it back into the editor so you can keep working on it.
4. Open the Tree view to browse the data as it will be read (see the value mapping below). Every table and array can be collapsed, and each entry shows its type and its path.
5. Copy or Download the result, or File → Clear input to start again. The full-screen icon at the right of the menu bar makes the studio fill the window; Esc returns.

Settings → Options… sets how the output looks: the indent for arrays broken over several lines, the line length after which a long array is broken (and longer lines are reported), and sort keys to order the keys in each table.

Formatting keeps your comments. Most TOML tools re-serialise the parsed data and lose every comment. This one rewrites the layout around them: comments on their own line, at the end of a line, and inside multi-line arrays all stay where they were, attached to the same key or element. Strings, numbers and dates are copied exactly as written, so 1_000, 0xDEAD_BEEF, 1.0 and a literal 'C:\path' survive unchanged.

What the checks catch. Beyond outright syntax errors, the usual TOML surprises are a key or [table] defined twice (often a [table] header that collides with a dotted key such as a.b = 1), an integer too large for 64 bits, and syntax from the TOML 1.1 draft that some parsers accept and others reject: line breaks or a trailing comma inside { inline tables }, the \e and \xHH escapes, and times without seconds (07:32). Mistakes from other formats get a hint: True (booleans are lowercase), null (TOML has none) and unquoted strings.

Converting. The same data can be turned into JSON, or JSON into TOML, through the API (see below). JSON has no comments, dates or 64-bit integers, so the conversion follows the value mapping in the specification.

Grammar. TOML 1.0.0. The parser is smol-toml, which also accepts some TOML 1.1 syntax; that syntax is reported as a warning (rule toml-1-1-syntax) so the document stays readable by TOML 1.0 parsers. A UTF-8 byte order mark is accepted with a warning. Only the first syntax error is reported, because after a syntax error the rest of the text has no reliable structure.

Positions. line and column are 1-based, and columns count Unicode code points, so an emoji counts as one character. offset is 0-based in UTF-16 code units (what a browser text box uses), so the editor can select the spot exactly. LF, CRLF and a lone CR each end a line.

Rules. Severity error makes the document invalid; warning and info do not. “Format fixes” means the formatted output no longer has the problem.

Formatting.

• One key = value per line with one space either side of =, no indentation, and no trailing spaces. A comment at the end of a line follows one space.
• Dotted keys are written without spaces around the dots; quotes that are not needed are removed.
• Blank lines: none at the start or end, at most one in a row, none directly after a table header, and exactly one before each header. Comments directly above a header (no blank line between) stay with the header.
• Arrays stay on one line unless they were already written over several lines, contain comments, or would make the line longer than the line length; then each element goes on its own line, indented by the indent setting per level, with a trailing comma. Blank lines between elements are kept (at most one).
• Inline tables are written { a = 1, b = 2 } on one line (an empty one as {}).
• TOML 1.1 syntax is rewritten to TOML 1.0: \e becomes \u001B, \xHH becomes \u00HH, 07:32 becomes 07:32:00.
• The output ends with one line break. A document that uses only CRLF stays CRLF; anything else becomes LF. A byte order mark is removed.
• Sort keys orders the keys of each table by UTF-16 code units, within each group of lines separated by blank lines; a comment directly above a key moves with it, and comments at the very top of the document stay there. Keys inside inline tables are sorted too. Tables themselves are never reordered: the order of [[array]] elements is data, and sub-tables belong to the element above them.
• Strings (including multi-line strings, byte for byte), numbers and dates are copied as written.
• The formatted document always parses to the same data as the input. This is checked on every format: if it ever did not, the input would be returned unchanged.

Value mapping to JSON (the Tree, value and TOML → JSON).

Fractions of a second beyond milliseconds are truncated (.999999 → .999). A key named __proto__ is an ordinary key.

JSON → TOML. The top level must be an object. Strings, booleans and numbers become key = value; numbers are copied as written, so 1.0 stays a float. Non-empty objects become [table] sections and non-empty arrays whose elements are all objects become [[array]] tables; objects inside other arrays become inline tables, and an empty object is {}. In each table the plain keys come first, then the sub-tables, so the key order can change. A null is an error naming its JSON Pointer (TOML has no null); so are an integer beyond 64 bits and a string with an unpaired surrogate. Duplicate JSON keys keep the last value. The output is formatted as above.

Statistics. tables counts tables below the root ([table] sections, dotted-key tables, inline tables and each [[array]] element); keys counts keys in all tables; arrays counts arrays, including arrays of tables; depth is 1 for a flat document and one more per level of table or array.

Not checked. Whether keys or values make sense for any particular program (Cargo, pyproject, Hugo and so on: use a schema for that); the order of keys; naming style (snake_case versus kebab-case); and whether a float or date can be represented exactly by the program that reads it.

API.

input can be a string field or a raw text/plain body. /api/toml/format returns valid, summary (counts of errors, warnings and infos), diagnostics, formatted, value and stats. An invalid document is a 200 response with valid: false and formatted and value set to null, not an HTTP error. The conversions return 422 unprocessable_input with the line and column (or JSON Pointer) when the input cannot be converted. The page has no size limit.

Errors make the document invalid. Warnings and information are style findings; the document still parses.