YAML to Properties Converter

Property lines follow a depth-first walk of the YAML in its original key order, so server.port appears before spring.datasource.url exactly when server was written before spring in the source — nothing is alphabetised. That makes a diff against a previous .properties export meaningful, since only genuine content changes move a line.

Two ways, and Spring Boot's relaxed binding actually accepts both for a simple List<String> or List<Integer>: index form (servers[0].host=api-1, servers[1].host=api-2 — the default here) and comma form (roles=admin,editor). The difference matters once the list holds objects rather than scalars: List<Address> or similar needs index form, because there is no way to comma-join a nested object onto one line, so comma mode automatically falls back to index form for exactly those lists and reports it in the status message. An empty list is written as endpoints= in comma mode (an explicit empty value) and simply omitted in index mode, since there is no index 0 to write — also reported in the message.

Because java.util.Properties.load(InputStream) — the constructor every plain .properties file is defined against — is specified to read the stream as ISO-8859-1, a single-byte encoding that has no representation for ü, ß, emoji, or most non-Latin scripts, so the historical convention is to write anything outside printable ASCII as a \uXXXX escape and let the loader decode it back to the real character. Spring Boot's own .properties loader follows the same convention by default. If your loader is one of the exceptions — Properties.load(Reader) (which reads whatever encoding the Reader was opened with, usually UTF-8), or a framework loader like Quarkus/SmallRye Config that explicitly reads .properties as UTF-8 — switch this tool's Unicode option to "Write UTF-8 characters as-is" and the output keeps ü and ß literally instead of escaping them.

All three are YAML-only concepts with no .properties equivalent, so all three are gone in the output. Comments are simply dropped — there is nowhere to put them in the flat format. Anchors (&name) and their aliases (*name) are resolved to the actual value they point to before flattening runs, so two services that both wrote options: *defaults in YAML end up as two separate, fully-expanded blocks of properties rather than sharing a reference. The << merge key is expanded the same way — its mapping is merged into the surrounding block and the literal << key never appears in the output, unlike this site's YAML to JSON converter, which keeps << verbatim because JSON has no concept of merging either but at least a literal << key does no harm there.

In Spring's bracket form: a key that doesn't match a plain bare identifier — because it contains a dot, a slash, a space, or a character outside letters, digits, underscore and hyphen — is wrapped in [ ] rather than joined with a dot, so it can't be confused with an extra level of nesting. A top-level key "api.timeout": 30 becomes [api.timeout]=30, and the same rule applies one level deep: settings: { "/health": true } becomes settings[/health]=true. This exactly mirrors how Spring's relaxed binding reads such keys back: my.map[/api] binds to a Map<String, ?> entry keyed by the literal string "/api".

Structure and values come back correctly for what survived the trip: dotted and bracketed keys unflatten into the same nesting, and indexed lists rebuild into sequences. What's gone for good is what this converter already discarded — comments (unless a # line sat directly above a key, which Properties to YAML does reattach), anchors and aliases, and whether a list was written as index form or comma form in the source, since both become the same plain sequence.