The Java .properties file format explained
How Java .properties files store key and value pairs, the separator and comment rules, escapes, and why converting to JSON keeps keys flat.
What a .properties file is
A .properties file is a plain text format Java uses for configuration, localization bundles and simple key and value storage. Each non-blank, non-comment line holds one property, with a key on the left and a value on the right. The class java.util.Properties reads and writes this format, which is why you see it across Spring, Log4j and countless application settings. Because it is just text with a light set of rules, it is easy to edit by hand but also easy to get subtly wrong.
Separators, comments and whitespace
A key is separated from its value by the first unescaped equals sign or colon, so db.port=5432 and db.port:5432 mean the same thing. Whitespace around the key is trimmed and whitespace immediately after the separator is ignored, though trailing spaces in a value are kept. Lines that begin with a hash or an exclamation mark are comments and are skipped entirely. If you need one of those separator characters inside a key, you escape it with a backslash so the parser does not split there.
Escapes and line continuations
Values can carry escape sequences borrowed from Java string literals. Backslash n, r, t and f produce the usual control characters, and backslash u followed by four hex digits inserts a Unicode character, which is how accented text like café survives an ASCII file. A line that ends with a single backslash continues onto the next line, and the leading whitespace of that continuation is discarded so you can indent for readability. This converter applies exactly these rules, decoding escapes when producing JSON and re-escaping them when writing properties back out.
Why the JSON keeps keys flat
Property keys are often dotted, such as spring.datasource.url, which tempts tools to expand each dot into a nested JSON object. This converter deliberately does not do that. Dotted keys are preserved verbatim as flat JSON keys because a dot in a key is not guaranteed to mean nesting, and flattening then unflattening can lose or merge keys. Keeping the mapping flat means the round trip from properties to JSON and back is lossless and predictable.