TOML to INI Converter

Convert TOML configuration files to INI format. Handles sections, key-value pairs, and nested tables.

TOML

INI

[database]
host = localhost
port = 5432
name = mydb

[server]
host = 0.0.0.0
port = 8080
debug = true

[server.tls]
enabled = false
cert = /etc/ssl/cert.pem

How TOML to INI conversion works

TOML and INI are both configuration file formats but use different conventions. TOML section headers like [database] map directly to INI sections. TOML string values lose their quotes in INI, and nested tables like[server.tls] become dot-notation INI sections.

Built and maintained by Meet Shah · Last updated 28 July 2026

What this tool is used for

Producing an INI configuration for a legacy tool from a TOML source.
Converting settings for software that predates TOML.
Flattening TOML tables into INI sections for an older parser.
Comparing a TOML file against an INI one in the same shape.
Migrating configuration during a downgrade or a platform change.

Frequently Asked Questions

What does TOML have that INI cannot express?: Real types (integers, floats, booleans, dates), arrays, arrays of tables, and nesting deeper than one level. INI has none of these — every value is a string and the structure is strictly two levels.
How is deep nesting flattened?: Into dotted section names, so [server.database.pool] becomes a literal section named that. It is readable, but the hierarchy is now a naming convention rather than structure, and no INI parser will reconstruct it.
What happens to arrays of tables?: TOML's [[products]] repeated-table syntax has no INI equivalent at all. Converters resort to indexed sections like [products.0], which is lossy and non-standard — the clearest sign this conversion is a downgrade.
Are TOML's date types preserved?: No. TOML has first-class offset date-times, local dates and times; INI stringifies them. Round-tripping back cannot restore the type, so a date becomes an ordinary string that every consumer must reparse.
Why would I convert this direction at all?: Only to feed a legacy consumer that requires INI. TOML was designed specifically to fix INI's ambiguity — it has a real specification where INI has none — so converting away from it is a compatibility concession.
How are TOML's typed values represented in INI?: As bare strings, because INI has no type system — every value is text and the reader decides. So `port = 8080` and `port = "8080"` become indistinguishable, and the consuming code must know which it expects.
Do INI parsers agree on comment syntax?: No. Some accept `;` only, some `#` too, and some allow a trailing comment on a value line while others treat it as part of the value. There is no INI specification, which is why converting into it loses guarantees.

Common errors and gotchas

Losing TOML's real types into INI strings, which record nothing about intent.
Flattening nested tables beyond INI's single level of sections, which needs a naming convention the reader must share.
Dropping arrays of tables, which have no natural INI representation.
Losing typed dates and times, which INI cannot express.
Assuming comment syntax is shared, when the two formats do not use the same characters.