TOML Converter
Convert TOML into structured or flat configuration text with parse checks and warnings when the target cannot preserve types or nesting.{{ report.converted_text }}
| Path | Type | Value preview | Copy |
|---|---|---|---|
| {{ row.path }} | {{ row.type }} | {{ row.preview }} |
Introduction
Configuration migrations rarely fail because a brace or quote moved. The harder problem is preserving what each value means when the destination format has a different idea of types, nesting, arrays, or names.
TOML organizes configuration as key-value assignments, tables, arrays, and arrays of tables. Strings, integers, floating-point numbers, booleans, and date or time tokens remain distinguishable in TOML. JSON and YAML can preserve much of that structure, while environment files, Java properties, and simple INI files usually reduce a nested document to flat names and text values.
| Target family | What usually survives | What needs review |
|---|---|---|
| JSON or YAML | Nested mappings, arrays, booleans, and ordinary finite numbers | Date/time interpretation and non-finite or very large numeric values |
| TOML rewrite | TOML-oriented structure and typed values | Comments and original formatting are not preserved |
| INI, environment, or properties | Leaf values represented as named text entries | Nesting, empty containers, arrays, escaping, and receiving-parser rules |
A path such as server.tls is more than a label during flattening. It becomes the bridge from a nested table to a flat setting name. Array positions also become part of the path, which means reordering an array can change the generated names even when the values stay the same.
Conversion is a migration draft, not proof that the destination application will accept the result. Compare the target application's schema, required names, quoting rules, and type coercion before replacing a working configuration.
How to Use This Tool:
Choose the receiving format first because that decision determines which structure can be preserved.
- Paste or load the TOML source. Correct any line-specific parse error before judging the converted text.
- Select Output format. Choose JSON, YAML, or TOML when nested structure matters; choose INI, environment, or properties only when the receiver expects flattened settings.
- Adjust indentation or key sorting for structured text. For flat output, choose the path notation and set an Environment prefix only when the receiving naming convention requires it.
- Review Path ledger and Type profile for missing paths, unexpected text values, or flattening warnings before copying the converted configuration.
Interpreting Results:
A successful parse means the source fits the supported TOML rules and produced at least one leaf value. It does not mean the target program recognizes the generated keys or treats every value with the intended type.
Warnings deserve attention when large integers, special floating-point values, date/time tokens, or flat targets are present. Compare several representative paths and then test the output with the actual receiving parser.
Technical Details:
TOML parsing builds a typed tree from assignments, dotted keys, tables, arrays of tables, arrays, inline tables, quoted strings, booleans, numbers, and date/time tokens. Comments are discarded during parsing, so they cannot be reconstructed in any output.
Transformation Core:
The parsed tree follows one of two paths. Structured targets serialize the tree directly, while flat targets visit every leaf and derive a name from its full path.
| Output | Transformation | Material consequence |
|---|---|---|
| JSON | Serialize the nested tree with 2 to 8 spaces of indentation | Date/time, special floats, and integers beyond safe precision become text |
| YAML | Serialize nested mappings and arrays; optional key sorting applies | Date/time tokens may be interpreted as timestamps by the receiver |
| TOML | Rewrite values, tables, and arrays of tables; optional key sorting applies | Comments, whitespace, and original key order may change |
| INI | Group flattened leaf paths into sections and keys | Nested shape and empty containers are not preserved as native structures |
| Environment | Replace path separators with underscores, apply an optional prefix, and optionally uppercase names | Every entry becomes name-and-text syntax |
| Properties | Write each leaf path as a property key | Receiver-specific escaping and type conversion still need verification |
Dot notation represents array positions with brackets, such as database.ports[0]. Slash notation uses path segments instead. Environment names replace dots, slashes, brackets, and unsupported characters with underscores, then add the optional prefix.
Finite integers within the safe numeric range and ordinary finite floats remain numbers. Integers beyond safe precision and TOML's inf or nan tokens remain text outside TOML to avoid silently changing their value. Date/time tokens remain source-like text for JSON and flat targets.
Source text is limited to 100,000 characters. The visible path ledger can show 25 to 1,000 rows, but that display limit does not truncate the converted configuration. Empty documents and unsupported or conflicting assignments stop conversion with a parse error.
Limitations:
This is a bounded TOML conversion model rather than a compatibility guarantee for every parser or application.
- Comments and original formatting are not retained.
- INI, environment, and properties output cannot preserve every TOML type or nested structure.
- Generated names can collide after punctuation is replaced; check the full path ledger for the source distinction.
- Validate the final text with the destination application's own parser and schema.
Worked Examples:
Nested service settings moved to environment names
A TOML table containing server.port = 8080 and server.tls = true produces paths for both leaf values. With prefix APP and uppercase names, the environment output includes APP_SERVER_PORT=8080 and APP_SERVER_TLS=true. Test those text values against the service because environment variables do not carry TOML's integer and Boolean types.
References:
- TOML v1.0.0, TOML project, January 11, 2021.
- RFC 8259: The JavaScript Object Notation Data Interchange Format, IETF, December 2017.
- YAML Version 1.2.2, YAML Language Development Team, October 1, 2021.
- Java Properties API documentation, Oracle.