Properties to YAML

Convert Java .properties files to YAML — handles dot-notation nesting and comments.

.properties input

or drop a file here

YAML output

app:
  name: MyApp
  version: 1.0.0
  debug: 'false'
db:
  host: localhost
  port: 5432
  name: mydb
  pool:
    size: 10
    timeout: 30000
server:
  port: 8080
  max-connections: 200

How .properties to YAML conversion works

Dot-separated keys like db.pool.size=10 are automatically converted to nested YAML structures. Comments (# or !) are stripped. Scalar values that could be misread as YAML booleans or numbers are quoted automatically.

For the reverse direction, try YAML to JSON. To go from Properties to JSON instead, use Properties to JSON.

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

What this tool is used for

Migrating a Java application's configuration to a YAML-based framework.
Turning a flat dot-notation file into the nested structure it was always describing.
Comparing two properties files by converting both and diffing the structure.
Producing a YAML fixture from an existing properties file.
Making a long properties file readable by grouping its keys.

Frequently Asked Questions

How does a flat key become nested YAML?: Dots are treated as depth: `server.port=8080` and `server.host=localhost` collapse into one `server:` block with two children. That is exactly how Spring Boot reads both formats, which is why the two files are interchangeable there.
Why did my value get quoted?: Because YAML would otherwise read it as something else. `yes`, `no`, `true`, `false`, `null` and `~` are quoted so they stay strings — the "Norway problem", where a country code of NO becomes boolean false. Values containing `:` or `#` are quoted too, since both start YAML syntax.
Which separators does a .properties file allow?: `=` and `:` both work, and the file format also allows a bare space. Whichever appears first wins here, so `url:jdbc:mysql://host` splits at the first colon and keeps the rest as the value — which is the correct reading.
Are comments preserved?: No. Lines starting with `#` or `!` (both are comment markers in `.properties`) are dropped, because a flat comment has no unambiguous home once keys are regrouped into a tree. Copy any that matter back in afterwards.
What about duplicate keys?: The last one wins, matching `java.util.Properties`. Watch for the subtler collision this format allows: `a.b=1` together with `a.b.c=2` cannot both exist in YAML, because `a.b` would have to be a string and a map at once.
What happens when a key is both a value and a prefix?: It cannot convert cleanly — `server=x` and `server.port=8080` want `server` to be a string and a map at once. The conversion has to rename one or fail, and silently dropping either loses configuration.

Common errors and gotchas

Assuming every dot is nesting. A key containing a literal dot becomes an unintended level.
Losing comments, which properties files carry and which often hold the only explanation.
Getting types wrong, since every properties value is a string and YAML will infer numbers and booleans.
Overlooking escaped characters, where properties files use backslash escapes that YAML does not share.
Colliding keys, where `a.b=1` and `a.b.c=2` cannot both exist in a nested structure.