Skip to content
ZeroServer.tools

YAML to Properties Converter

Convert YAML to Java .properties format. Nested keys become dot-separated (parent.child=value). Handles arrays, strings, numbers, and booleans.

or drop a file here
.properties Output
Properties output will appear here...

About YAML to Properties Converter

Java .properties files use a flat key=value format where nested structure is expressed through dot-separated keys (e.g., database.host=localhost). Spring Boot, Quarkus, and many Java frameworks accept both YAML and .properties formats, but some tools and legacy systems only support .properties. This converter flattens a YAML hierarchy into the equivalent flat key=value pairs, handling nested objects, arrays (indexed askey.0=value), strings, numbers, and booleans.

Built and maintained by Meet Shah · Last updated

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.

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?
They become indexed keys — `servers[0]`, `servers[1]` — which is the convention Spring's relaxed binding understands. Plain `java.util.Properties` has no notion of a list at all, so it will see those as three unrelated keys with odd names.
Why did my multi-line string collapse?
Because a properties value is one line. YAML's `|` block scalar keeps newlines and `>` folds them into spaces; flattened into properties, an embedded newline has to be escaped as `\n` or the file breaks at that point.
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?
By index into the key — `servers[0].host` or `servers.0.host` depending on the framework. Spring accepts the bracket form; a plain properties reader does not, so the target's convention decides.

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.

Related Converters tools

Private & free — this tool runs entirely in your browser.

IndieKitShip your Next.js startup in days.affiliate