Overview
Check TOML syntax and see the equivalent JSON at the same time. The validator handles tables, basic and literal strings, integers, floats, booleans, arrays, and ISO dates, and reports the line number of any problem. Everything parses locally in the browser.
How It Works
Paste your TOML into the editor. The syntax card immediately shows a green valid marker or a red error naming the line and the problem, such as a missing equals sign or an unsupported value type. When the document parses, the equivalent JSON appears in the output box below, so you can confirm the structure the TOML will produce. Edits re-validate live; there is no button to press.
Step-by-Step Usage Guide
- Paste the TOML document into the editor.
- Read the syntax verdict; errors name the line and show the offending text.
- Compare the JSON output against the structure you intended.
- Fix issues and re-check, then copy the JSON if you need it.
Technical Specifications & Standards
The validator is a line-oriented TOML reader written for this tool, which makes its coverage explicit. It understands comments, table headers with dotted paths such as [server.tls], unquoted and quoted keys, booleans, integers, floats, basic strings with standard escapes, literal strings in single quotes, single-line arrays, and ISO-formatted dates, which are kept as strings in the JSON view. Several TOML 1.0 features are outside its scope and will be flagged rather than misread: multi-line basic and literal strings, inline tables, and true arrays of tables, since [[name]] headers are parsed as an ordinary nested table rather than an array. Two more behaviors to watch: duplicate keys do not raise an error, the later value silently overwrites the earlier one, and dotted keys in a key position are kept as literal names with dots rather than nesting. For configs within that subset the JSON view is an exact structural mirror, which is the quickest way to spot a typo in a table path.
Targeted Use Cases
- Checking a Cargo-style or project config file before committing it.
- Finding the exact line that breaks a generated TOML file.
- Visualizing what structure a TOML file produces in a parser's data model.
- Teaching TOML syntax by editing a sample and watching the JSON change.
Notes & Gotchas
- Expand multi-line strings and inline tables to single-line equivalents before validating here.
- Do not rely on the validator to catch duplicate keys; the later value wins silently.
- Use [[array]] headers knowing they are treated as plain nested tables by this parser.
- Keep dates in ISO form so they pass and appear as strings in the JSON view.
Frequently Asked Questions
Why does my multi-line string fail?
The validator reads TOML line by line and does not implement multi-line basic or literal strings from the full 1.0 spec. Collapse the string to one line, with escapes, and it will validate.
Are duplicate keys an error?
No. The parser assigns the later value over the earlier one, matching no error from the spec but also not warning you. Watch the JSON output for values you did not expect.
How are dates handled?
ISO-formatted dates pass validation and appear as strings in the JSON view, since the target is a structural preview rather than typed date objects.
Is the JSON output a lossless conversion?
Within the supported subset, yes: tables, scalars, strings, and arrays map directly. Unsupported constructs fail validation instead of being approximated, so a green verdict means the JSON reflects the document.