Converters
Properties to YAML Converter
Rebuild application.properties into application.yml — dotted keys unflattened into real nesting, key[0] lists reassembled, and your # comments kept.
In short
Convert Java .properties to YAML online: dotted keys unflattened, key[0] lists rebuilt, comments kept, ambiguous values quoted for SnakeYAML — 100% client-side.
By NaveenKumar T · Updated
Learn: TOML vs YAML vs JSON: Choosing a Configuration Format
- Instant in-browser conversion
- Validates input first
- Keeps your # comments as YAML comments
Runs entirely in your browser — nothing you paste or open here is uploaded, logged, or stored.How we handle data →
Example
Properties to YAML: input and output
A Spring Boot application.properties with a comment, a JDBC URL, an indexed list, a comma-joined list, and three deliberately ambiguous values — a version-looking decimal, a yes/no word, and a leading-zero code.
# Database
server.port=8080
spring.datasource.url=jdbc:postgresql://db:5432/shop
app.cors.origins[0]=https://app.example.com
app.cors.origins[1]=https://admin.example.com
app.feature.flags=alpha,beta
app.version=1.20
app.enabled=yes
app.region.code=007
app.greeting=Gr\u00fc\u00df dich
app.description=A two-line description that \
continues hereserver:
# Database
port: 8080
spring:
datasource:
url: jdbc:postgresql://db:5432/shop
app:
cors:
origins:
- https://app.example.com
- https://admin.example.com
feature:
flags: alpha,beta
version: "1.20"
enabled: "yes"
region:
code: "007"
greeting: Grüß dich
description: A two-line description that continues here
The # Database comment reattached directly above server, the two cors.origins entries rebuilt into a proper list, app.feature.flags stayed a single comma-joined string (index mode does not split values), and "1.20" / "yes" / "007" all came back quoted — each for a different YAML 1.1 safety reason explained above.
Learn more
How Properties to YAML conversion works
The parser implements the java.util.Properties.load grammar by hand, the same rules the JDK itself follows: a logical line can span several physical lines when it ends in an odd number of backslashes (the continuation strips leading whitespace from the next line before joining), a line starting with # or ! (after leading whitespace) is a comment, and a key ends at the first unescaped =, : or plain whitespace — whichever comes first — with the separator's own surrounding whitespace then skipped. Standard escapes are decoded on the way in: \t \n \r \f, \uXXXX for any character, and a backslash before any other character simply yields that character (so \: inside a key stops it from being read as the separator).
Dotted and bracketed keys are split back into real YAML nesting: server.port unflattens to server: { port: ... }, and app.endpoints[0].path rebuilds a list under endpoints with path as a key of its first element. A conflict — the same prefix used as both a value and a parent of other keys, such as a=1 alongside a.b=2 — has no YAML representation and is reported as an error naming the exact line, rather than silently picking one.
The typing step is deliberately conservative, because a round trip should never silently change what a value means: true/false (exact lowercase) become YAML booleans, a bare integer or decimal becomes a number, and everything else — including anything that merely LOOKS numeric but isn't in that exact form, like 1.20 or a value with a leading zero — stays a string. On the way out, any string a YAML 1.1 loader (SnakeYAML, which is what Spring Boot itself uses) would misread as something else gets wrapped in double quotes, which is the page's honest, visible answer to "why did my value come back quoted."
When to convert Properties to YAML
This is the direction most Spring Boot teams actually take in practice — properties files accumulate for years and eventually need restructuring into the nested, profile-friendly shape YAML allows, or a team standardizing on application.yml needs to convert a stack of legacy .properties files in one pass. It also turns a flat, .env-style properties dump into a starting point for a Helm values.yaml, and it's a fast way to review an old configuration file by its actual structure rather than by scanning a wall of dotted keys.
Value in .properties → YAML scalar (infer mode)
The conservative rules that decide what stays a string, shown against the values that actually trip people up.
| .properties value | YAML output | Why |
|---|---|---|
| 8080 | 8080 | A plain integer |
| 1.20 | "1.20" | Looks numeric, but Number("1.20") stringifies back to "1.2" — not an exact round trip, so it stays a string |
| 007 | "007" | A leading zero would be read as octal by a YAML 1.1 loader |
| true | true | Exact lowercase boolean |
| yes | "yes" | A YAML 1.1 boolean-like word — quoted so SnakeYAML reads it as text |
| (empty) | "" | An empty value stays an empty string, not null |
| 2026-09-18 | "2026-09-18" | Looks like a date; kept as a string and quoted for safety |
Help
Frequently asked questions
Everything you need to know about the Properties to YAML.
01What happens to a property key that appears twice in the file?
The last occurrence wins, matching java.util.Properties.load itself: if server.port=8080 appears once and again later as server.port=9090, only 9090 reaches the YAML. Duplicate keys are legal but silent in .properties files, so if that's a mistake rather than an intentional override, search the source file for the key before converting — the converter has no way to flag it as an error.
02Why did some values come back in quotes?
Because SnakeYAML — the library Spring Boot itself uses to read YAML — implements YAML 1.1, not the newer 1.2 core schema, and 1.1 resolves several bare words and shapes to types other than a string: yes, no, on, off, y and n all become booleans (the "Norway problem" — a country code of NO reads as false), 1.20 parses as the float 1.2 and silently drops the trailing zero, a leading-zero value like 007 is read as octal, and null / ~ becomes null. This converter quotes exactly the values a 1.1 loader would misread this way — it is the honest, conservative choice, since an unquoted false where you meant the two-letter code "NO" is a much worse bug than one extra pair of quotes. Switch the Types option to "Keep everything as a string" if you'd rather every value came back quoted, uniformly.
03How do indexed keys like servers[0].host become YAML?
Contiguous zero-based indices become a proper YAML sequence — servers[0].host and servers[1].host produce a two-item list under servers, each with a host key. A gap in the indices (servers[0] and servers[2], with no [1]) has no clean sequence form, so that level is rebuilt as a mapping keyed by the numeric strings "0" and "2" instead, and the status message says so — treat a gap as a signal to check the source file, since Spring Boot's own relaxed binding would have the same trouble with it. A bracketed segment that ISN'T all digits, like [api.timeout] or [/health], is never treated as an index regardless of mode — it becomes a literal YAML mapping key, quoted if it contains characters like a dot that YAML's plain-key form can't safely carry. The Arrays option's "none" setting disables index reconstruction entirely and keeps every [N] as a literal string key — useful for a properties file that was never meant to bind to a Spring Boot list.
04Are comments and blank lines kept?
A comment line (starting with # or !) immediately above a key is kept and reattached as a YAML comment directly above the corresponding key in the output — that's the one piece of information a .properties file carries that this site's other config converters normally have to drop. A trailing comment after a value on the same line isn't a thing .properties syntax supports, so there's nothing to lose there, and blank lines are simply blank lines — they don't attach to anything and aren't preserved as blank lines in the output, since YAML doesn't need them for readability the way a flat file does.
05How are line continuations and \uXXXX escapes handled?
A physical line ending in an odd number of backslashes continues onto the next line: the trailing backslash and the following line's leading whitespace are both removed, and the remaining text is joined onto the end of the current logical line before any further parsing happens — so a key or value can legitimately span several lines in the source file and still become a single YAML scalar. \uXXXX escapes decode to the real character (\u00fc becomes ü) wherever they appear, in keys or values, which is what makes round-tripping this site's YAML to Properties output lossless for non-ASCII text.
06Can I convert a multi-profile file with #--- separators?
A comment line whose content is exactly --- (so #--- or !---) is treated as a document boundary, matching the convention Spring Boot 2.4+ uses for multi-profile .properties files (and the exact separator this site's YAML to Properties converter emits for a multi-document YAML input). Everything before it becomes one YAML document, everything after becomes the next, and the output joins them with the standard YAML --- document-start marker.
07Does converting back with YAML to Properties reproduce the same .properties file?
Values match, but formatting doesn't fully: YAML to Properties re-derives ISO-8859-1 \uXXXX escaping and Spring's list convention fresh, so a file that mixed comma-form and index-form lists by hand normalises to whichever single convention is selected on that page. Reattached comments come back exactly above their key, but blank-line spacing used to group related settings is not restored, since YAML never recorded it.
Keep working
Related tools
YAML to Properties
Converters
YAML Validator
Full YAML 1.2 validation with the exact line and column of every error — catch the indent bug before your pipeline does.
JSON to YAML
Converters
YAML Formatter
Normalize any YAML to clean, consistent style — uniform indentation, canonical quoting, validation built in.
CSV to YAML
Converters
JSON to TOML
Converters