{{ summaryHeading }} {{ summaryPrimary }} {{ summaryLine }} {{ formatBadge }} {{ keyBadge }} Local parse
TOML conversion inputs
Use one configuration up to 100,000 characters. Source text is excluded from the URL because it may contain secrets.
{{ sourceError }}
{{ fileStatus || 'Drop one TOML or TXT file onto the textarea.' }}
JSON and YAML preserve nested structure. INI, .env, and properties flatten scalar paths and need review.
The shipped two-space default produces compact, reviewable output.
spaces
On is the neutral shipped setting and gives stable diffs.
{{ sort_keys ? 'Alphabetical mappings' : 'Source insertion order' }}
Dot notation produces paths such as server.host; slash notation produces server/host.
Example: APP turns server.host into APP_SERVER_HOST.
On is the neutral shipped setting.
{{ uppercase_env ? 'Uppercase names' : 'Preserve lowercase names' }}
The default shows 200 rows while every row remains available to CSV and DOCX exports.
rows
{{ configExportStatus }}
{{ report.converted_text }}
{{ ledgerExportStatus }}
PathTypeValue previewCopy
{{ row.path }}{{ row.type }}{{ row.preview }}
{{ chartExportStatus }}
{{ workflowFeedback }}

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.

Configuration target formats and preservation tradeoffs
Target familyWhat usually survivesWhat needs review
JSON or YAMLNested mappings, arrays, booleans, and ordinary finite numbersDate/time interpretation and non-finite or very large numeric values
TOML rewriteTOML-oriented structure and typed valuesComments and original formatting are not preserved
INI, environment, or propertiesLeaf values represented as named text entriesNesting, 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.

  1. Paste or load the TOML source. Correct any line-specific parse error before judging the converted text.
  2. Select Output format. Choose JSON, YAML, or TOML when nested structure matters; choose INI, environment, or properties only when the receiver expects flattened settings.
  3. 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.
  4. 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.

TOML conversion behavior by output format
OutputTransformationMaterial consequence
JSONSerialize the nested tree with 2 to 8 spaces of indentationDate/time, special floats, and integers beyond safe precision become text
YAMLSerialize nested mappings and arrays; optional key sorting appliesDate/time tokens may be interpreted as timestamps by the receiver
TOMLRewrite values, tables, and arrays of tables; optional key sorting appliesComments, whitespace, and original key order may change
INIGroup flattened leaf paths into sections and keysNested shape and empty containers are not preserved as native structures
EnvironmentReplace path separators with underscores, apply an optional prefix, and optionally uppercase namesEvery entry becomes name-and-text syntax
PropertiesWrite each leaf path as a property keyReceiver-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: