Properties to YAML Converter

Runs locally

Turn application.properties into application.yml — profiles, lists and comments included.

Properties

YAML

2 documents

# Spring Boot application.properties
spring:
application:
name: orders
# Datasource — the placeholder is resolved by Spring at startup
datasource:
url: jdbc:postgresql://${DB_HOST:localhost}:5432/orders
username: orders_app
jpa:
open-in-view: false
server:
port: 8080
app:
greeting: Café ouvert
cors:
allowed-origins:
- https://app.example.com
- https://admin.example.com
---
spring:
config:
activate:
on-profile: prod
server:
port: 80
logging:
level:
root: warn
 
Guide

Same configuration, different shape

Spring Boot reads application.properties and application.yml into the same flat set of keys, so converting between them should change nothing about how the application is configured. In .properties every key is spelled out in full — spring.datasource.url, spring.datasource.username — while YAML writes the shared prefix once and nests the rest under it. This converter uses the same parser as the Properties Viewer, so escapes, line continuations and all three separators (=, : and a space) are read exactly as java.util.Properties reads them.

Lists use indexes in .properties — app.hosts[0], app.hosts[1] — and become YAML sequences; objects inside lists, such as app.servers[0].port, become sequences of maps. A file split into documents with #--- (Spring Boot 2.4 and later) becomes a multi-document YAML file separated by ---, and spring.config.activate.on-profile moves along with its document, so profile-specific overrides keep applying to the same profiles. ${…} placeholders are copied as they are for Spring to resolve at startup.

Values are typed where it is safe: 8080 and true are written unquoted, while strings YAML would misread — on, off, yes, no, leading zeros — are quoted. Spring binds either form to the same property, so this only changes how the file reads. When a key is both a value and a parent (a=1 next to a.b=2), YAML cannot express it; the key is kept flat and flagged. To go the other way, use YAML to Properties.

application.properties

spring.datasource.url=jdbc:mysql://${DB_HOST}/shop
spring.datasource.hikari.maximum-pool-size=10
app.admins[0][email protected]
app.admins[1][email protected]
#---
spring.config.activate.on-profile=test
spring.datasource.url=jdbc:h2:mem:shop

application.yml

spring:
  datasource:
    url: jdbc:mysql://${DB_HOST}/shop
    hikari:
      maximum-pool-size: 10
app:
  admins:
    - [email protected]
    - [email protected]
---
spring:
  config:
    activate:
      on-profile: test
  datasource:
    url: jdbc:h2:mem:shop

The second document overrides the datasource only when the test profile is active, in both files.

How each .properties construct maps to YAML, and back
.propertiesapplication.ymlNotes
server.port=8080server: port: 8080Each dot is one level of nesting
app.hosts[0]=a app.hosts[1]=bapp: hosts: - a - b[n] indexes become a list, in index order
app.servers[0].port=9000app: servers: - port: 9000Objects inside lists work the same way
#------Starts a new document (Spring Boot 2.4+)
spring.config.activate.on-profile=prodspring.config.activate.on-profile: prodActivates that document for a profile
url=${DB_HOST:localhost}url: ${DB_HOST:localhost}Placeholders are copied verbatim; Spring resolves them
name=Caf\u00e9name: CaféEscapes decoded to YAML; re-escaped for .properties
flag=onflag: 'on'Quoted: SnakeYAML would read on as true
# comment# commentKept above the key that follows it

Where people get caught

A key that is also a parent

logging.level=info next to logging.level.root=warn cannot both exist in YAML, because logging.level would have to be a value and a map at once. The later key is kept flat and listed in the warnings; remove or rename one of them.

Gaps in list indexes

hosts[0] and hosts[2] with no [1] produce a list with a null in the middle. Spring binds that to an empty element, which is rarely what was meant.

Old-style profile documents

spring.profiles=dev is the pre-2.4 way to activate a document and is rejected by newer Spring Boot versions. Use spring.config.activate.on-profile; the converter warns when it sees the old key.

Comments attached to the wrong key

A comment is placed above the key that followed it. A comment describing a whole section may end up above that section’s first nested key — check section headers after converting.

About converting .properties to YAML

How it works in 4 steps · 4 common use cases · 4 questions answered

How it works

  1. 1.Paste or drop an application.properties file.
  2. 2.Choose 2 or 4 spaces, typed values and whether to keep comments.
  3. 3.Read any warnings about keys that could not be nested.
  4. 4.Download application.yml or swap direction to convert back.

Common use cases

  • •Moving a Spring Boot service from .properties to application.yml
  • •Reading a long .properties file as a tree
  • •Converting profile-specific files into one multi-document YAML
  • •Preparing config for a Kubernetes ConfigMap in YAML

FAQ

Does Spring Boot treat the YAML exactly like the .properties file?

Yes — both are flattened into the same keys. Differences only appear for things YAML cannot express, such as a key that is both a value and a parent, which the converter reports.

How are profiles converted?

Each #--- document becomes a YAML document after ---, keeping its spring.config.activate.on-profile key, so it applies to the same profile.

Are ${…} placeholders changed?

No. They are copied as-is, including defaults like ${PORT:8080}, for Spring to resolve at startup.

What about \uXXXX escapes?

They are decoded, so Caf\u00e9 becomes Café in the YAML, which Spring reads as UTF-8.

Related tools