TOML to Properties Converter

Convert TOML configuration files to Java .properties format. Flattens nested sections with dot notation and handles strings, numbers, and booleans.

TOML Input

.properties Output

database.host=localhost
database.port=5432
database.name=myapp

server.host=0.0.0.0
server.port=8080
server.debug=true

cache.ttl=3600
cache.max_size=1000

About TOML to .properties Conversion

TOML (Tom's Obvious, Minimal Language) is a popular configuration format used in Rust projects, Hugo, and many modern tools. Java applications often use the .properties format, which is a flat key=value file. This converter flattens TOML sections into dot-notation keys — for example,[database] with host = "localhost" becomesdatabase.host=localhost. Quoted strings are unquoted, and inline arrays are converted to comma-separated values.

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

What this tool is used for

Migrating configuration from a TOML-based tool to a Java service that reads properties.
Flattening TOML sections into the dot-notation keys the target expects.
Producing a properties file without retyping an existing TOML config.
Comparing a TOML file against a properties file in the same flattened shape.
Extracting configuration into a flat form for grepping or templating.

Frequently Asked Questions

How are nested TOML sections named?: The header becomes a single key segment with its dots replaced by underscores, so [database.primary] with host gives database_primary.host. Keeping the dots would erase the section boundary, because dots in a .properties key are ordinary characters and imply no nesting whatsoever.
What happens to arrays?: They become comma-separated values, the form Spring's @Value and Environment binding already expect. Quotes around each element are stripped, so an element containing a comma becomes indistinguishable from two elements — split those into separate numbered keys instead.
Why does my quoted string keep its comment?: Inline comment stripping is skipped when a value starts with a quote, so that a # inside a string survives intact. The trade-off is that name = "app" # note keeps both quotes and comment. Move such comments onto their own line, where they are preserved as # lines in the output.
Will Java read the output as UTF-8?: Not through Properties.load(InputStream) — that overload is specified to read ISO-8859-1, so umlauts or CJK text arrive as mojibake. Use the Reader overload with an explicit charset, or escape non-ASCII as \uXXXX. This is the most common surprise when moving config into Java.
Which TOML features are not handled?: Arrays of tables ([[products]]), multi-line basic strings, multi-line arrays, and dotted keys inside a table body. This is a line-oriented converter for flat section/key/value files rather than a full TOML parser, so anything spanning lines needs checking by hand.

Common errors and gotchas

Losing TOML's real types, which it does record, into properties strings that record nothing.
Flattening arrays of tables into indexed keys, which is a convention the reader may not share.
Overlooking that TOML dates and times are typed values with no properties equivalent.
Producing key collisions where a table and a value share a name after flattening.
Assuming comments transfer, which they do not survive the structural change.