Properties file viewer, key list and converter
Paste a Java or Spring .properties file to see it highlighted, tidied and explained. The viewer normalises separators and ordering without losing your comments, the key list shows every key with its value, line number and whether it is duplicated, empty, padded with invisible whitespace or pointing at a ${…} placeholder nothing defines, and the converter turns dotted keys into nested YAML or JSON and back again.
The parts of a .properties file that bite
A .properties file looks like a list of key=value pairs and is parsed by rules most editors do not implement. Three characters separate a key from its value, two start a comment, a backslash at the end of a line joins the next one, and a key defined twice is not an error — the last one silently wins.
Every one of those rules is behind a bug someone has spent an afternoon on. Here is what the parser actually does with your file.
.properties
# the sale override server.port=8080 db.url:jdbc\:mysql://db/shop timeout 30 banner= spaced out colour=#ff0000 hosts=a,\ b server.port=9090
What loads
server.port = 9090 db.url = jdbc:mysql://db/shop timeout = 30 banner = " spaced out" colour = #ff0000 hosts = a,b 7 lines, 6 keys — server.port is defined twice and the first value never reaches the app.
Note what did NOT happen: the # in the colour value is not a comment, the escaped colon in the JDBC URL stayed in the value instead of splitting the key, and the leading spaces in banner survived because only a trailing space is stripped.
| Written as | Parsed as | Why it matters |
|---|---|---|
| a=1, a:1, a 1 | The same entry | All three separate a key from a value. A space is a separator only when no = or : follows it. |
| # note and ! note | Comments | Only at the start of a line. A # anywhere else — a hex colour, a URL fragment — is part of the value. |
| key\ with\ spaces=1 | One key containing spaces | A backslash escapes the character after it, which is the only way a key can hold a space, = or :. |
| url=jdbc\:mysql://h/db | jdbc:mysql://h/db | Colons in a value need no escape; the one in the key does, and generated files often escape both. |
| value=a,\ (newline) b | a,b | A trailing backslash continues the line and the next line’s leading whitespace is dropped. |
| a=1 then a=2 | a is 2 | Not an error, not a warning. The last definition wins and the earlier one is unreachable. |
| msg=caf\u00e9 | café | Properties files are ISO-8859-1 by default in older Java, so non-ASCII is escaped as \uXXXX. |
Where people get caught
A duplicated key is the most common production surprise
Two definitions of server.port do not fail the build, and the one you edited may be the one that is ignored. The viewer flags every repeated key, marks which occurrence wins, and can rewrite the file keeping only that one.
Trailing whitespace is part of the value
password=hunter2 followed by a space loads as "hunter2 ". No editor shows it and no diff makes it obvious. Values that end in whitespace are called out here.
key= and a missing key are different things
An empty value is a defined empty string, so a @Value default or a getProperty fallback never fires. If you want the default, remove the line rather than clearing it.
${other.key} is resolved by Spring, not by the file
Plain java.util.Properties does no substitution at all, and Spring fails to start when a placeholder resolves to nothing. Every ${…} in the file is listed with whether this file defines it or supplies a ${key:default}.
Converting to YAML has to guess at types
Everything in a .properties file is a string. 8080 becomes a number and true becomes a boolean in YAML, which is usually what you want and is occasionally wrong — a version like 1.20 becomes 1.2. Turn the inference off when the values must stay strings.
A key cannot be both a value and a branch
a=1 and a.b=2 are fine side by side in properties and impossible in YAML, where a would have to be a scalar and a map at once. Those keys are kept flat and listed rather than one of them being dropped.
About the .properties viewer
How it works in 4 steps · 4 common use cases · 6 questions answered
About the .properties viewer
How it works in 4 steps · 4 common use cases · 6 questions answered
How it works
- 1.Paste a .properties file into the editor. It is parsed as you type — separators, escapes, line continuations and all.
- 2.View and clean rewrites it with one separator style, in file or alphabetical order, optionally dropping duplicate keys and keeping every comment with the entry it belongs to.
- 3.Keys lists every key with its value and line, filtered by duplicated, empty, padded or placeholder-using, and copies the names on their own.
- 4.Convert turns dotted keys into nested YAML or JSON — and YAML or JSON back into properties — with array positions written as key[0].
Common use cases
- •Finding why a setting is ignored, when the same key is defined twice in one file
- •Listing every key in a config to check against the documentation or a test
- •Migrating an application.properties to application.yml without hand-indenting it
- •Turning a YAML config back into properties for a service that only reads them
FAQ
Which key wins when the file defines one twice?
The last one, which is what java.util.Properties does when it loads the file. Duplicates are flagged with the lines they are on, and "Keep the last" rewrites the file to contain only the values that actually load.
Does it understand escapes and line continuations?
Yes. \n, \t, \uXXXX and escaped separators are decoded, and a line ending in an odd number of backslashes is joined with the next one before anything else looks at it.
Are my comments lost when I reformat?
No. A comment stays with the entry below it, so it follows that entry even when the file is sorted alphabetically. A comment followed by a blank line is treated as a section header and stays where it is. You can also drop all comments deliberately.
How are dotted keys converted to YAML?
server.port becomes a nested port under server, and indexed keys like hosts[0] become a YAML list. You can switch nesting off to get one flat YAML key per line, which is useful when the dots are part of the name rather than a hierarchy.
Can I compare two properties files?
Yes — that is the Properties Compare page. It parses both files and reports the keys only one side defines and the values that differ, instead of diffing them line by line.
Is anything uploaded?
No. The file is parsed in your own tab, which is what makes it safe to paste a config containing connection strings or credentials.