YAML to Properties Converter

Convert YAML to a Java .properties file. Nested keys join with dots, lists become servers[0] as Spring writes them (or servers.0), values are kept exactly as written, and the output is escaped the way Java reads it.

YAML Input · stays on your device, never in the shared link

or drop a file here

.properties Output

List keys

Properties output will appear here...

About YAML to Properties Converter

Java .properties files hold flat key=value lines, so this converter joins each level of YAML nesting with a dot (database.host=localhost). Lists become servers[0], servers[1], the form Spring Framework's own YAML flattener produces, or servers.0 for readers that expect that form; an empty list becomes an empty value, and an empty map, which has no properties form, is left out with a note. Values are copied exactly as written, so 2.10, 0755 and 2024-03-01 stay as typed, and the tool lists any value that Spring Boot, which reads YAML by YAML 1.1 rules, would read differently.

Newlines from block scalars become \n, backslashes are doubled, a leading space is escaped, and =, : and spaces inside keys are escaped so the key ends where it should. Anything outside printable ASCII is written as \uXXXX, because java.util.Properties and Spring Boot both read a properties file as ISO-8859-1. Comments are dropped and anchors are expanded, and a file with several YAML documents separated by --- has to be converted one document at a time.

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

What this tool is used for

Moving configuration from a YAML-based framework to one that reads Java properties.
Flattening a nested structure into the dot-notation keys a legacy service expects.
Producing a properties file for an environment that cannot read YAML.
Comparing a YAML config against an existing properties file in the same shape.
Extracting a subset of configuration in a flat, greppable form.

How it works in practice

A worked example

A Spring Boot developer needs a service's application.yml as a .properties file, because the integration test loads its configuration through @TestPropertySource, which cannot read YAML files.

Input

server:
  port: 8080
  servlet:
    context-path: /api
spring:
  datasource:
    url: jdbc:postgresql://db:5432/orders
    username: orders_app
app:
  version: 2.10
  cors:
    allowed-origins:
      - https://shop.example.com
      - https://admin.example.com
  banner-text:

Output

server.port=8080
server.servlet.context-path=/api
spring.datasource.url=jdbc:postgresql://db:5432/orders
spring.datasource.username=orders_app
app.version=2.10
app.cors.allowed-origins[0]=https://shop.example.com
app.cors.allowed-origins[1]=https://admin.example.com
app.banner-text=

Every level of nesting became one dot-separated part of the key, so url, nested under spring and datasource, came out as spring.datasource.url. The two allowed origins became allowed-origins[0] and allowed-origins[1], the bracket form Spring Boot's documentation uses when it flattens a YAML list, so the test binds them back into the same list the service sees. The empty banner-text, which the YAML parser reads as null, was written with nothing after the equals sign, and Java's Properties loads that line as an empty string. The colons in the JDBC URL needed no escaping, because Properties ends the key at the first unescaped equals sign, colon or space, which on that line is the equals sign, and takes the rest of the line as the value.

The edge case that catches people

The version is the one value Spring itself reads differently. The converter copies it as written, so the file says app.version=2.10, but the service reading the original application.yml gets 2.1: Spring Boot parses YAML with SnakeYAML, which follows YAML 1.1 and types an unquoted 2.10 as a floating-point number, so the trailing zero is gone before the property is bound. The test would see 2.10 while the running service sees 2.1. The converter lists that line in its note on values Spring reads differently, and the fix belongs in the YAML: quoted, as version: "2.10", it is a string to both readers. The same rules turn an unquoted 0755 into 493 and NO into false.

When not to use this tool

It cannot convert an application.yml that keeps several profiles in one file, separated by lines of three hyphens. The converter uses js-yaml's single-document load, so instead of converting the first part it reports the error "expected a single document in the stream, but found more" and produces nothing. Spring Boot does allow the same layout in a .properties file, with a line of exactly #--- and no leading whitespace between documents, so you can convert each YAML document on its own and join the results with that line. That combined file still will not serve this scenario, though, because Spring's documentation says a multi-document properties file cannot be loaded through @PropertySource or @TestPropertySource either, so each profile the test needs has to go in a file of its own.

Frequently Asked Questions

How does nested YAML flatten?: Each level of nesting becomes a dot: a database: block containing host: localhost becomes database.host=localhost. Spring Boot reads both formats through the same binder, which is exactly why the two are interchangeable in a Spring project.
What happens to lists?: Each item gets its index in brackets — servers[0], servers[1] — which is how Spring's own YAML loader flattens a list and what its binder reads back into a List. Choose the servers.0 option if your reader expects the dotted form. An empty list becomes servers= rather than disappearing.
What happens to a multi-line string?: A properties value has to fit on one line, so the newlines a | block keeps are written as \n, and a > block has already folded its lines into spaces. Java's Properties turns each \n back into a real newline when it loads the file, so the value arrives intact.
Are comments and anchors kept?: Neither. Comments have no unambiguous home once keys are flattened, and anchors are resolved — <<: *defaults expands into a full copy at every use, so shared structure that appeared once in YAML appears repeatedly in the output.
Which format should a Spring project use?: YAML for hierarchy and profiles, properties when a value must be overridden by an environment variable — DATABASE_HOST maps onto database.host by Spring's relaxed binding rules either way, but the flat form makes the mapping obvious to whoever is debugging.
How is a list of objects flattened?: The index goes in the middle of the key: servers[0].host=a, servers[1].host=b, the shape Spring binds into a List of objects, or servers.0.host with the dotted option. Plain java.util.Properties sees either form as flat keys with no list meaning, so the code reading it has to rebuild the list.
Are values kept exactly as written?: Yes. 2.10, 0755, yes and 2024-03-01 come through as typed, because the YAML is read without number, boolean or date conversion. Spring Boot does convert them, by YAML 1.1 rules (2.10 to 2.1, 0755 to 493), so the tool lists each value Spring would read differently; quoting it in the YAML makes both agree.
How are accented letters and emoji written?: As \u escapes: Zürich becomes Z\u00FCrich, and an emoji becomes two escapes, one per UTF-16 unit. Java's Properties.load and Spring Boot both read a properties file as ISO-8859-1, so raw UTF-8 bytes would arrive garbled, while the escapes read back correctly in every Java reader.

Common errors and gotchas

Flattening a list and losing its ordering semantics, since indexed keys are a convention rather than a structure.
Assuming comments carry over, which they do not once the structure is flattened.
Producing keys that collide when a value and a nested map share a name.
Losing type information that YAML expressed, since properties values are all strings.
Overlooking multi-line block scalars, which need escaping to survive a single-line properties value.