The .properties format in practice
A .properties file is the plain key/value format read by java.util.Properties. Spring Boot’s application.properties, ResourceBundle translation files such as messages_de.properties, log4j.properties, gradle.properties, Kafka and Flink client configs, and many Jenkins and Maven settings all use it. The syntax is looser than most people expect: a key can be separated from its value by =, by : or by plain whitespace, comments start with # or !, a trailing backslash continues the value on the next line, and non-ASCII characters are traditionally written as \uXXXX escapes. Teams that edit the same file for years end up with all of these styles mixed together.
Using the formatter
Paste the file or drop it on the editor; dotted keys such as spring.datasource.url let the detector tell it apart from an INI or .env file. Output is produced as you type, and Ctrl/Cmd+Enter formats on demand when live formatting is switched off. Switch to the Tree view to see the keys and the values Java will actually load, with \u00e9 already decoded to é and continuation lines joined into one string. Copy the result with Ctrl/Cmd+Shift+C.
The parser and printer are built into PasteKit and follow the rules of Properties.load. Database passwords and API keys, which these files tend to hold, are handled entirely inside your browser tab.
Options
- Separator sets how every key is joined to its value:
key=value(the default and the most common style),key = value,key:valueorkey: value. Entries that used bare whitespace, likeserver.port 8080, get the chosen separator too, which removes a frequent source of confusion. - Align separators pads keys so the separators form a column. Alignment is worked out per block, where a block is a run of entries between blank lines, so one very long key in the datasource section does not shift the logging section.
- Sort keys orders entries by key. Comments written directly above a key travel with it, standalone comment blocks stay at the top or bottom, and ordering is case-sensitive, so
Server.portsorts beforeapp.name. Spring and Java do not care about order, so this is safe, and it makes two environments’ files easy to diff.
What is never rewritten
Keys and values are printed exactly as you wrote them. Escapes are not decoded and re-encoded, so caf\u00e9 stays caf\u00e9 and a literal café stays literal. An escaped space in a key (first\ name) is kept. A key with no value is kept as a bare key. Values that continue across lines with \ keep their line breaks; the continuation lines are re-indented by four spaces so it is obvious they belong to the key above. Leading whitespace before keys is removed, blank-line runs shrink to one, Windows line endings become \n, and a byte-order mark is dropped with a note.
Escaping gotchas
The backslash is the troublemaker. Java treats \t, \n, \r and \f as control characters and silently drops a backslash in front of any other character, so a Windows path like C:\temp\new loads with a tab and a line break where \t and \n were. Write such paths with forward slashes or doubled backslashes. A path containing \u, for instance C:\users, is worse: Java rejects it as a malformed escape, and this formatter reports it too. Encoding is the other trap: Properties.load(InputStream) reads ISO-8859-1, while ResourceBundle has read UTF-8 since Java 9, so \u escapes remain the safest way to ship accented text.
Examples
Spring Boot config with three separator styles
Whitespace, colon and equals separators all become " = ", lined up in one column.
server.port 8080
spring.datasource.url=jdbc:mysql://db.internal:3306/orders
spring.datasource.username : orders_app
spring.jpa.hibernate.ddl-auto=validate
management.endpoints.web.exposure.include=health,info
server.port = 8080
spring.datasource.url = jdbc:mysql://db.internal:3306/orders
spring.datasource.username = orders_app
spring.jpa.hibernate.ddl-auto = validate
management.endpoints.web.exposure.include = health,info
German message bundle, sorted
Keys are put in alphabetical order, the comment moves with checkout.title, and the \u escapes and continuation are untouched.
# messages_de.properties
checkout.title=Zur Kasse
checkout.total=Gesamtbetrag
cart.empty=Ihr Warenkorb ist leer
greeting.long=Willkommen zur\u00fcck, wir haben \
neue Angebote f\u00fcr Sie.
account.delete.confirm=Konto wirklich l\u00f6schen?
account.delete.confirm=Konto wirklich l\u00f6schen?
cart.empty=Ihr Warenkorb ist leer
# messages_de.properties
checkout.title=Zur Kasse
checkout.total=Gesamtbetrag
greeting.long=Willkommen zur\u00fcck, wir haben \
neue Angebote f\u00fcr Sie.
log4j appender with a colon separator
The conversion pattern, with its braces and percent signs, passes through untouched while every line switches to key: value.
log4j.rootLogger=INFO, stdout
log4j.appender.stdout=org.apache.log4j.ConsoleAppender
log4j.appender.stdout.layout=org.apache.log4j.PatternLayout
log4j.appender.stdout.layout.ConversionPattern=%d{ISO8601} %-5p [%t] %c - %m%n
log4j.rootLogger: INFO, stdout
log4j.appender.stdout: org.apache.log4j.ConsoleAppender
log4j.appender.stdout.layout: org.apache.log4j.PatternLayout
log4j.appender.stdout.layout.ConversionPattern: %d{ISO8601} %-5p [%t] %c - %m%n
gradle.properties aligned per block
The two blocks separated by a blank line are aligned independently of each other.
# Gradle
org.gradle.jvmargs=-Xmx2g -Dfile.encoding=UTF-8
org.gradle.parallel=true
android.useAndroidX=true
kotlin.code.style=official
# Gradle
org.gradle.jvmargs =-Xmx2g -Dfile.encoding=UTF-8
org.gradle.parallel=true
android.useAndroidX=true
kotlin.code.style =official
Common errors and how to fix them
| Error | Cause | Fix |
|---|---|---|
Invalid unicode escape '\u12zz' on line 1 | A \u escape is followed by something other than four hexadecimal digits, so Java would throw IllegalArgumentException when loading the file. | Write exactly four hex digits, for example \u00e9 for é, or type the character directly if the file is read as UTF-8. |
Invalid unicode escape '\users' on line 1 | A Windows path such as C:\users\app contains \u, which Java reads as the start of a unicode escape. | Use forward slashes (C:/users/app) or double every backslash (C:\users\app). |
Duplicate key 'spring.datasource.url' (first defined on line 2) | The same key appears twice. This is a warning: Java keeps the last value, which may not be the one you meant to change. | Delete the stale entry so only one definition remains. |
Removed a UTF-8 byte-order mark (BOM) from the start of the input | The file was saved with a BOM, which Properties.load reads as part of the first key, so that key silently stops matching. | Nothing to do in the output; save the original file as UTF-8 without BOM so the first property is found. |
Frequently asked questions
Does the formatter convert accented characters to \u escapes?
No. Escapes and literal characters are both written back unchanged. Use native2ascii or your IDE if you need to convert a whole file one way or the other.
Can it format Spring Boot application.properties?
Yes. Spring reads these files with standard Properties rules, so a consistent separator and sorted keys change nothing at runtime. Placeholders such as ${DB_HOST:localhost} are kept as written.
Will sorting break multi-line values?
No. A value continued with a trailing backslash moves as one unit with its key, together with the comment lines directly above it.
Should I use = or : as the separator?
Java accepts both, and whitespace too. = is by far the most common in Spring and i18n files, so it is the default; choose whatever your codebase already uses.
Can I convert application.properties to YAML?
There is no direct converter here. The Tree view shows the parsed keys and values, which helps when rewriting them by hand as application.yml.