| Field | Value | Copy |
|---|---|---|
| {{ row.label }} | {{ row.value }} |
{{ normalizedToml }}{{ normalizedYaml }}{{ iniText }}{{ envText }}{{ propertiesText }}| Document | Path | Type | Preview | Copy |
|---|---|---|---|---|
| Doc {{ row.docIndex }} | {{ row.path || '(root)' }} | {{ formatTypeLabel(row.type) }} | {{ row.preview }} |
| Path | Types | Docs | Example |
|---|---|---|---|
| {{ row.path }} | {{ row.types }} | {{ row.docs }} | {{ row.example }} |
TOML is a plain text configuration format built to stay readable to people while still preserving useful data types such as strings, numbers, booleans, arrays, tables, and date-time values. That balance is why it shows up in application settings, development tools, package metadata, and local environment configuration where human editing still matters.
This converter takes TOML text or a dropped .toml file, parses the structure, and then shows the same data in several different forms. You can inspect cleaned TOML, YAML, JSON, INI-style text, environment variable assignments, Java properties output, a flattened path ledger, and a schema summary without manually rewriting the file first.
That is especially useful when one source of truth has to serve several jobs. A developer may want normalized TOML for version control, an automation step may prefer JSON or YAML, and an operations handoff may only need leaf values expressed as simple KEY=value lines.
The most practical gain often comes from understanding the shape of the configuration before you convert it. Summary badges, overview rows, path previews, and schema grouping make it easier to spot deep nesting, repeated sections, empty containers, or keys with awkward names before those details turn into export mistakes.
It is still important to match the output to the job. YAML and JSON preserve nested structure well, while INI, environment variable text, and properties output are convenience views generated from scalar leaves. They are useful for review and simple handoffs, but they are not a promise that every TOML feature round-trips perfectly into those flatter formats.
The quickest workflow is to paste the TOML, wait for the parser to settle, and then move through the result tabs based on the decision you need to make. If you are checking whether the input is valid and consistently formatted, stay with normalized TOML. If you need a portable data view for another tool or script, YAML and JSON are usually the clearest next stop.
Flat text exports help when the important question is "what are the leaf settings" rather than "what is the exact tree." The Paths and Schema tabs are better when you are auditing structure, comparing sections, or trying to understand where a repeated or unexpected key is coming from.
| View | Best for | What to watch |
|---|---|---|
| TOML | Cleaning spacing, confirming how the parser understood tables, arrays, and scalar values | Formatting can change even when the underlying data stays the same |
| YAML and JSON | Passing structured data to other systems or reviewing the full object tree | Quote style, wrapping, and key order can affect readability even when meaning is unchanged |
| INI, Env, Properties | Inspecting or exporting scalar leaves as simpler key-value text | Objects and arrays are not preserved as first-class structures in these flatter outputs |
| Paths and Schema | Auditing document shape, repeated paths, types, and example values | Preview trimming affects what you see in the table, not what the CSV export includes |
Advanced options are there to tune presentation rather than to change the underlying TOML meaning. You can choose JSON spacing, YAML indentation and line width, alphabetize YAML keys, force YAML quoting, switch quote style, avoid YAML anchor reuse, choose dot or slash path notation, cap the visible path preview, and control environment key prefixing and letter case.
If the file is unfamiliar, start with Overview, then Paths, then Schema before exporting anything. That sequence makes it much easier to catch unexpected arrays, empty sections, or odd key names before they disappear into a flatter format.
After the page loads, parsing happens locally in the browser. The tool normalizes newline characters, runs a TOML parser against the current text, and stops immediately if the input is invalid. When parsing fails, it shows the parser error instead of guessing, which keeps downstream YAML, JSON, and flat-text exports tied to real parsed state rather than partial text.
Once the TOML has been parsed, the tool walks the resulting tree recursively. Objects contribute keys, arrays contribute indexed children, and scalar leaves contribute previews and type labels. That single traversal feeds the summary badges, overview rows, path table, and schema table, so the structural views all reflect the same parsed document rather than separate ad hoc interpretations.
YAML output is generated from the parsed tree with controls for indentation, wrapping, key sorting, quote forcing, quote style, and anchor reuse. JSON output can be pretty-printed or minified. The TOML tab attempts to serialize the parsed structure back into TOML, which is helpful for cleaning up inconsistent whitespace, quoting, and table layout after the original file has already proven valid.
| Output | Derivation | Practical consequence |
|---|---|---|
| Normalized TOML | Serialize the parsed structure back into TOML text | Good for cleanup and consistency checks after valid parsing |
| YAML and JSON | Render the same parsed tree in structured interchange formats | Best match when nested objects and arrays need to stay visible |
| INI | Group scalar leaves by the first path segment and normalize later segments into safe keys | Useful for simple settings, but not a lossless representation of deep TOML structure |
| Env and Properties | Flatten scalar leaves into path-based keys, with optional prefixing and uppercasing for env output | Convenient for shell or application configuration review, but nested meaning becomes path text |
| Paths and Schema | Record every discovered location, type, and preview, then group unique paths for schema reporting | Helps you understand shape and type stability before choosing an export |
Path formatting is intentionally explicit. In dot mode, ordinary identifier-like keys become paths such as server.host, while keys that contain punctuation or spaces are preserved with bracketed quotes so the path still points back to the original key safely. In slash mode, segments read more like file paths, and literal slashes inside key names are escaped rather than silently merged into the separator.
Scalar-only exports are built from leaves and nothing else. That means empty objects, empty arrays, and intermediate containers still appear in the path audit, but they do not become KEY=value records by themselves. If your TOML relies on arrays of tables, nested sections, or mixed types at the same path, JSON or YAML will usually remain the more faithful output.
The preview limit changes only the size of the visible path table. When a large document would produce too many rows for comfortable reading, the page trims the preview and labels it accordingly, while copy and CSV export for the full path set still continue to use every discovered row. That keeps the browser view usable without silently discarding data from exported analysis.
From a privacy perspective, this package does not implement a per-conversion upload step. Parsing, formatting, copying, and downloading all happen in the browser after the page has loaded. Even so, configuration files often contain credentials or host details, so a redacted sample is still the safer choice whenever structure, not live secrets, is what you need to inspect.
.toml file onto the input area.The Overview tab is a compact structural summary rather than a semantic review of your settings. Top-level keys tell you how busy the root is, total nested keys show overall surface area, scalar values approximate how many leaves can become plain text exports, and maximum depth tells you how far down a manual reviewer may need to travel before seeing the whole picture.
The Paths tab is a row-by-row ledger of what the traversal found. Each row records the document index, the flattened path, the detected type, and a short preview value. Empty objects appear as {} and empty arrays as [], which is important because blank containers can still carry meaning in configuration even when they have no scalar leaves yet.
The Schema tab answers a different question. Instead of listing every occurrence, it groups the document by unique path and shows which types appeared there, how many documents contained that path, and a representative example. If a path shows multiple types, treat that as a signal to slow down before exporting because many downstream systems assume one stable shape per key.
A simple service block such as the bundled sample shows why the different views matter. When you paste a TOML file with a root title plus nested server, database, and feature tables, the JSON and YAML tabs preserve those sections as nested objects, while the flat-text tabs turn the scalar leaves into keys like SERVER_HOST, database.user, or sectioned INI entries depending on the export.
title = "Example"
[server]
host = "127.0.0.1"
port = 8080In that short example, the Paths view makes the transition explicit by showing entries such as title, server.host, and server.port. The Schema view then confirms that those paths carry stable scalar types, which means the flat exports are unlikely to surprise you.
A more nested case is where structure review becomes more valuable than raw conversion. If a table contains an array such as hosts = ["a", "b"], the path audit shows indexed leaves like server.hosts[0] and server.hosts[1] in dot mode or server/hosts/0 and server/hosts/1 in slash mode. That is precise enough for analysis, but it also shows why array semantics are easier to preserve in JSON or YAML than in INI or environment-variable text.
database.user or servers[0].port.